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ABSTRACT 


Integrated  Modular  Avionics,  or  IMA,  has  been  a  notable  trend  in  aircraft  avionics  for  the 
past  two  decades,  promising  significant  size,  weight,  and  power-consumption  (SWAP) 
gains,  radically  increased  sensors  fusion,  and  streamlined  support  costs.  Despite  the 
demonstrated  success  of  IMA  systems  in  commercial  airliners  such  as  the  Airbus  A3 80 
and  the  Boeing  787,  military  rotorcraft  in  the  service  of  the  United  States  Joint  services 
have  yet  to  benefit  significantly  from  this  technology.  At  long  last,  that  may  be  about  to 
change. 

The  Future  Vertical  Lift  Family  of  Systems  (FVL)  initiative  was  launched  in 
2008,  with  the  aim  of  re-inventing  the  entire  U.S.  rotary  wing  fleet.  Within  the  FVL 
program’s  projected  timeline,  many  signs  point  to  the  emergence  of  a  second-generation 
IMA  technology  (IMA2G),  which  will  leverage  extensive  virtualization  and  software- 
defined  functionality  to  deliver  further  SWAP  gains,  fault-tolerance,  and  system 
capability.  Development  efforts  are  indeed  already  underway  to  integrate  such  advanced 
IMA  features  into  the  FVL’s  Joint  Common  Architecture. 

This  thesis  assesses  the  maturity  of  IMA2G  critical  path  technologies,  validates 
the  alignment  between  IMA2G  benefits  and  desired  FVL  attributes,  and  describes  the 
operational  impact  that  software-defined  avionics  and  mission  systems  might  have  on 
future  rotary  wing  aircraft. 
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I.  INTRODUCTION 


A.  SOFTWARE-DEFINED  AVIONICS  AND  THE  FVL  PROGRAM 

The  concept  of  software-defined  avionics  and  mission  systems  is  an  emerging 
field  with  great  promise  for  reducing  size,  weight,  and  power-consumption  (SWAP),  and 
life-cycle  costs  for  modem  aircraft,  while  simultaneously  increasing  reliability  and 
providing  new  capabilities.  It  is  a  natural  outgrowth  of  existing  Integrated  Modular 
Avionics  (IMA)  architectures  introduced  to  many  production  aircraft  over  the  course  of 
the  last  decade,  and  is  often  referred  to  as  Second-Generation  Modular  Avionics 
(IMA2G).  First-generation  IMA  combines  many  system  functions  using  shared 
processing  resources  but  only  makes  limited  use  of  virtualization  to  abstract  (and  thus 
eliminate)  hardware  components.  Even  so,  the  application  of  IMA- architecture  to  such 
aircraft  as  the  Boeing  787  and  Airbus  A3 80,  has  demonstrated  the  ability  to  “reduce 
electronic  control  unit  cost,  improve  the  commonality  of  parts,  minimize  the  number  of 
computing  modules,  and  reduce  wiring,  number  of  connectors  and  weight”  (Jakovljevic 
&  Ademaj,  2013,  p.  1).  The  development  of  IMA2G  is  an  attempt  to  continue  progress 
along  those  lines  via  extensive  virtualization  and  the  convergence  of  critical  vehicle 
management  functions  within  a  logically  partitioned,  software-defined,  network 
computing  environment. 

The  promise  of  second-generation  Integrated  Modular  Avionics  has  made  it  an 
attractive  avenue  of  interest  for  the  Department  of  Defense’s  Future  Vertical  Lift  (FVL) 
program.  This  ambitious  initiative  seeks  to  replace  the  current  Army,  Navy,  Coast  Guard, 
and  Air  Force  rotary-wing  fleets  with  an  advanced  new  rotary-wing  platform  scalable 
from  lightweight  scout/utility  aircraft  to  ultra-heavy  transports  (Defense  Industry  Daily, 
2013).  The  resulting  FVL  Family  of  Systems  (FVLFS)  will  include,  manned,  unmanned, 
and  optionally  manned  aircraft,  and  all  will  share  a  “common  open-systems”  avionics 
architecture,  intended  to  allow  seamless  interoperability  (U.S.  Department  of  the  Army 
[USA],  2011,  p.  1).  In  short,  the  FVL  program’s  Initial  Capabilities  Documents  (ICD) 
describes  a  sum  of  characteristics  unlike  anything  flying  today,  or  even  on  the  immediate 
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horizon.  It  seems  reasonable  then  to  propose  that  the  optimum  avionics  architecture  for 
such  a  system  may  also  be  beyond  anything  flying  today. 


B,  PROBLEM  STATEMENT 

The  majority  of  military  aircraft  in  service  today  with  U.S.  Joint  Forces  are 
burdened  with  heavy,  bulky,  inefficient  and  often  unreliable  avionics  and  mission- 
systems  designed  under  a  Federated  Architecture  Model.  The  FVL  will  have  to  do  better, 
if  it  is  to  live  up  to  its  lofty  goals.  The  ground-up,  fleet-wide  reinvention  of  rotary-wing 
aviation  proposed  by  the  program  is  indeed  a  golden  opportunity  to  break  free  of  present 
limitations — and  do  so  in  a  cost-effective  manner. 

Though  the  benefits  of  pursuing  advanced  IMA2G  architectures  in  the  civil 
aircraft  field  have  been  discussed  in  the  literature,  application  to  military  systems  has 
remained  largely  unspoken.  We  seek  to  address  this  shortcoming,  within  the  specific 
context  of  the  FVL — which  may  perhaps  be  the  most  significant  aircraft-development 
program  of  the  coming  decades. 

C,  PURPOSE  OF  THIS  PAPER 

This  thesis  explores  projected  benefits  of  IMA2G  and  how  they  align  with  the 
desired  characteristics  and  capabilities  of  the  DOD’s  next-generation  helicopter  fleet.  We 
will  also  attempt  to  project  upon  possible  downstream  implications  (both  advantageous 
and  otherwise)  on  FVL  operations  and  support,  based  on  the  adoption  of  IMA2G.  The 
intent  is  to  develop  a  timely  and  relevant  analysis  and  conclude  with  recommendations 
for  development  of  FVL’s  Joint  Common  Architecture  (JCA). 

D,  RESEARCH  QUESTIONS 

This  thesis  will  focus  on  answering  the  following  questions: 

•  How  might  software-defined  avionics  and  mission  systems  help  achieve 
key  operational  requirements  listed  within  the  Future  Vertical  Lift  Family 
of  Systems  ICD? 

•  Would  an  IMA2G-configured  FVL  Family  of  Systems  be  suitable  for 
employment  as  envisioned  by  the  DOD’s  concept? 
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•  What  is  the  current  level  of  technological  risk  associated  with  committing 
to  an  IMAG2 -based  systems  architecture  for  FVL? 

•  Given  the  potential  impacts,  as  well  as  the  potential  risks,  is  IMA2G 
(software-defined  avionics) — the  right  fit  for  the  FVL  program? 

E.  ORGANIZATION  OF  THIS  PAPER 

The  analysis  of  the  advanced  avionics  architectures  as  applied  to  the  FVL 
program  will  proceed  as  follows: 

•  Review  As-Is  state:  The  Federated  Model,  IMA. 

•  Introduce:  IMA2G 

•  Survey:  challenges  to  IMA2G  implementation. 

•  Introduce:  Future  Vertical  Lift  program  and  proposals 

•  Survey:  Joint  Common  Architecture  (JCA)  -  current  research  directions 

•  Findings:  technological  maturity/development  risk  for  IMA2G 

•  Findings:  alignment  comparison  between  IMA2G  characteristics  and  FVL 
desired  outcomes. 

•  Synthesis  and  Projection:  operational  vignette 

•  Conclusion:  recommendations  for  the  development  of  the  FVL  JCA 
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II.  LITERATURE  REVIEW 


A.  TECHNOLOGIES 

The  history  of  aircraft  avionics  may  well  have  begun  with  a  simple  lead  weight, 
suspended  on  the  end  of  a  short  length  of  cotton  twine.  This  arrangement  formed  the 
rudimentary  turn-and-slip  indicator  on  a  1909  Wright  Flyer,  and  within  certain  limits,  it 
worked  well  enough  (Curran,  1992,  p.  7).  Over  subsequent  decades,  successive 
generations  of  technology  have  provided  far  more  accurate  and  capable  airborne  systems, 
but  that  progress  has  been  accompanied  by  its  own  ever-increasing  trade-offs.  The  size, 
weight,  power-consumption  (SWAP)  growth  associated  with  complex,  on-board 
equipment  logically  works  in  opposition  to  any  efforts  at  increasing  aircraft  range,  speed 
or  payload.  In  multiple  studies,  it  has  also  been  convincingly  correlated  with  swelling 
unit  acquisition-costs  (Dryden,  Britt,  &  Binnings-Depriester,  1981),  and  support/ 
maintenance  challenges  (USAF  Science  and  Advisory  Board  [SAB],  2011). 

1,  The  Scope  of  the  Challenge 

With  the  advent  of  digital  technology  and  integrated  circuit  microprocessors,  the 
focus  of  aircraft  avionics  development  turned  increasingly  toward  software.  A  2009 
NASA  report  on  the  increasing  complexity  of  avionics  software  explains  that  “in  a  period 
of  forty  years,  the  percent  of  functionality  provided  to  pilots  of  military  aircraft  [through 
software]  has  risen  from  8%  in  1960  (F-4  Phantom)  to  80%  in  2000  (F-22  Raptor)  ...  The 
F-22A  is  reported  to  have  2.5  million  lines  of  code”  (Dvorak,  2009,  p.  30).  Despite  the 
perception  that  software  is  faster  and  less  expensive  to  develop  than  commensurately 
complex  hardware,  this  upward-trend  in  code-derived  functionality  has  done  little  or 
nothing  to  arrest  costs.  According  to  a  paper  published  in  2009  by  Navy  analyst  Henry 
Eskew,  inflation-adjusted  fly-away  costs  for  fixed-wing  fighter  aircraft  increased  600% 
from  the  Korean  War  vintage  F-86  Sabre  to  the  80’s-delivery  F-18C.  (Eskew,  2000, 
p.  211)  By  the  early  1990s,  data  from  contemporary  military  aircraft  acquisition 
programs  indicated  that  up  to  50%  of  program  costs  were  related  to  avionics.  (Curran, 
1992,  p.  7).  There  is  no  indication  that  this  upward  trend  has  abated.  Meanwhile, 
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sustainment  and  service-life-extension  phases  helped  perpetuate  a  vicious  cycle. 
Expensive  aircraft  require  long-service  lives  to  justify  their  development  costs  and  hold 
the  line  until  their  replacements  achieve  full  operating  capacity.  In  order  to  facilitate  that 
long  service  life,  they  must  be  built  from  the  outset  with  redundant  capacity  and  leading- 
edge  systems — ^which  of  course,  make  them  more  expensive  to  begin  with. 

2,  Modularity  and  the  Federated  Systems  Approach 

Most  aircraft  in  current  U.S.  military  service  today  feature  avionics  built  along  a 
Federated  Systems  Model.  This  architecture  dates  back  to  the  late -Vietnam  era,  and  grew 
out  of  an  approach  described  as  “Form,  Fit,  Function”  (Helfrick,  2000,  p.  315),  which 
was  intended  to  contain  costs  and  streamline  maintenance.  The  analogy  to  the  household 
lightbulb  detailed  in  Albert  Helfrick’ s  Principles  of  Avionics,  provides  a  ready 
illustration.  It  is  easy  to  replace  a  failed  light  bulb  with  a  new  one  or  even  a  new  type  of 
light  bulb  because  prevailing  standards  ensure  that  the  socket  dimensions  are  the  same, 
and  the  current-draw  within  limits.  The  “form”  and  “fit”  are  compatible,  and  the 
“function”  is  specified  within  the  standard  in  terms  of  output  -  not  how  that  output  is 
achieved  within  the  unit  itself  Clearly,  an  FED  “bulb”  produces  light  in  a  completely 
different  manner  than  an  old  incandescent  bulb,  but  the  standards  governing  light  sockets 
or  household  electrical  wiring  did  not  have  to  be  re-written  to  accommodate  the  new 
technology  (Helfrick,  2000,  p.  316).  Consequently,  one  does  not  have  to  re-wire  one’s 
home  in  order  to  switch  to  new  lightbulbs,  reducing  cost  of  ownership. 

In  terms  of  federated  aircraft  avionics,  these  standardized,  interchangeable  “light 
bulbs”  are  FRUs,  or  Fine  Replaceable  Units.  FRUs  are  the  so-called  “Black  Boxes”  that 
make  up  individual  function-based  avionics-components.  The  “line-replaceable” 
appellation  requires  three  things: 

•  The  component  can  be  removed  or  installed  by  a  single  maintainer  with 
minimal  or  no  tools. 

•  A  replacement  FRU  can  be  installed  in  the  place  of  a  failed  unit  without 
extensive  testing  or  calibration. 

•  The  FRU  itself  must  be  sufficiently  rugged  to  endure  rough  handling  prior 
and  during  installation.  (Helfrick,  2000,  p.  315) 
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In  the  Federated  Model,  the  arrangement  of  LRUs  mirrors  the  funetional 
deeomposition  of  a  given  aireraft’s  avionies  suite.  Eaeh  funetion-area  will  be  served  by  a 
series  of  intereonneeted  deviees  that  perform  sub-funetions  in  series.  Most  of  these 
deviees  are  miero-proeessor  eontrolled,  and  as  many  as  praetieal  are  built  into  LRU-form, 
to  faeilitate  maintenance,  and  simplify  airframe  design.  Replication  and  coordination  are 
hallmarks  of  Federated  Systems.  Standardized  form,  fit,  and  function  prevails  down  to 
the  level  of  physical  interface  between  sub-components.  Integration  between  functional 
branches  is  intentionally  limited,  and  generally  only  occurs  at  a  very  high  level.. 
Processing  resources  are  not  shared. 

There  are  advantages  (Hagen,  Hurt,  &  Sorenson,  2013)  to  this  loose  federation  of 
compartmentalized  systems: 

•  There  is  no  single  point  of  failure  for  the  entire  system. 

•  The  performance  and  reliability  of  a  functional  branch  is  not  dependent  on 
the  system  as  a  whole,  simplifying  both  certification  and  trouble-shooting. 

•  The  need  for  high-performance  computing  assets  is  reduced,  since  system 
tasks  are  distributed  across  many  individual  processors. 

These  advantages,  however,  are  mitigated  (Fuchsen,  2009)  by  some  notable 
drawbacks: 

•  Lack  of  integration  between  functional  branches  means  that  each  branch 
has  many  potential  single  points  of  failure. 

•  Decomposing  the  system  into  standardized  LRU’s  increases  wire-count, 
system  weight,  and  power-consumption,  and  inhibits  efficient  resource 
pooling. 

•  Unneeded  memory  or  processing  capacity  in  one  functional  unit  or  branch 
is  essentially  “trapped”  -  it  cannot  be  leveraged  to  increase  the 
performance  of  another  unit  or  branch  which  may  be  over-burdened  at  the 
moment.  As  a  result,  a  large  amount  of  excess  capability  must  be  designed 
in  to  every  component  from  the  outset,  increasing  cost,  complexity,  and 
weight. 

Perhaps  the  most  salient  shortcoming  of  the  federated  systems  model  (as  it  has 
historically  been  implemented)  is  the  fact  that  “Form,  Fit,  and  Function”  was  only 
applied  as  far  as  the  physical  level.  Differing  network  protocols,  bus  connections,  and 

7 


software  languages  limited  reuse  across  platforms.  This  means  that,  in  practice,  the 
majority  of  LRU’s  are  unique  components,  specific  to  a  single  type-model  aircraft. 
SYSCO  AG  researcher  Rudolf  Fuchsen  describes  the  resulting  impact:  “The  increasing 
number  of  separate  devices,  each  with  its  own  development,  certification  and  update 
process  and  the  need  to  maintain  spare  parts  for  all  these  devices  in  all  configurations 
became  more  and  more  a  logistic  and  economic  problem.”  (Fuchsen,  2009,  p.  7.B.5-1) 

For  a  deployed  military  force,  reliant  on  the  support  of  complex  aircraft, 
maintained  in  austere  forward  environments,  such  “economic”  problems  can  easily 
translate  to  operation  shortcomings. 

3.  First-Generation  Digital  Data  Bus  Standards 

With  the  advent  of  micro-processor-equipped  Line-Replaceable  Units  in  military 
and  civil  aviation,  it  was  clear  that  a  standardized  network  protocol  was  required  to  allow 
the  dispersed  system  components  to  exchange  data.  The  military  solution  was  designated 
MIL-STD-1553B.  First  conceived  in  the  late  sixties  and  fully  implemented  by  1973,  this 
standard  describes  a  half-duplex  digital  data  bus  utilizing  time-division  multiple-access 
(TDMA),  command-and-response  protocol  between  up  to  31  remote  terminals  (IE:  LRUs 
or  other  system  components).  Communications  are  regulated  by  dual-redundant  bus- 
controllers  with  dual-redundant  bus  cables  that  specify  the  sending  unit  and  the  receiving 
unit  for  each  transaction.  A  minimum  throughput  of  1  Mbps  (megabit-per-second)  was 
called  for.  (“MIL-STD-1553,”  n.d.)  If  more  than  31  terminals  are  required,  separate 
1553B  data  buses  are  added,  and  linked  via  controlled  gateways. 

Envisioning  more  modest  requirements  and  wishing  to  keep  costs  in  line,  the  civil 
aviation  sector  arrived  at  its  own  Ist-generation  standard:  ARINC  429.  This  schema  did 
without  the  multiplexing  specified  in  the  military  standard,  relying  instead  of  parallel 
communication  paths  between  all  networked  devices  for  separate  sending  and  receiving 
channels.  This  one-way  data-bus  architecture  limited  the  speed  and  throughput,  and  could 
only  integrate  20  devices  on  a  single  network  backplane.  The  double-weight  of  wiring 
required  for  separate  send  and  receive  channels  also  contributes  to  system  overhead  -  a 
shortcoming  avoided  by  the  1553 ’s  time-division  multiple-access  (TDMA) 
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communications  protocol.  Even  with  these  inherent  limitations,  the  429  bus  was  broadly 
adopted  and  has  remained  a  eommon  standard.  The  follow-on  teehnology,  ARINC  629, 
developed  by  Boeing  in  the  1980s,  finally  adopted  TDMA  with  eollision  avoidanee,  but 
does  without  the  1553B’s  bus-eontrollers  by  employing  priority  message  algorithms. 
(Curran,  1992,  p.  22) 

The  development  of  the  both  eivil  and  military  digital  data  bus  standards 
paralleled  the  evolution  of  ground-based  network  computing  and  there  was  elose 
interaction  between  the  emerging  fields.  Fiber-optie  transmission  media  was 
subsequently  integrated  into  both  (the  revised  MIL-STD-1773  was  the  result),  inereasing 
data  throughput  to  as  mueh  as  50  Mbps. 

As  network  throughput  inereased  and  parallel  advances  were  made  in  proeessor 
speed  and  memory  eapaeity,  aireraft  system  designers  were  tempted  to  begin  integrating 
more  eapability  into  fewer  and  fewer  diserete  hardware  modules.  The  SWAP  advantages 
of  integration  still  had  to  be  balaneed,  however,  against  the  ruggedness  and  ease-of- 
maintenanee  afforded  by  loosely  federated  modular  arehiteeture.  These  seemingly 
divergent  strategies  lead  eventually  to  the  development  of  an  entirely  new  model  in  the 
1990s:  Integrated  Modular  Avionics  or  IMA. 

4,  Integrated  Modular  Avionics  (IMA)  -  Generation  One 

How  exactly  can  an  avionics  system  be  both  integrated  and  modular?  The  key 
eoneept  is  the  LRM,  or  Line  Replaeeable  Module.  This  differs  from  the  previously 
deseribed  LRU  insomueh  as  it  is  a  generic  proeessor,  eapable  of  performing  a  variety  of 
funetions  depending  on  installation  and  software.  (Curran,  1992,  p.  24)  Otherwise,  the 
standardized  form-faetor  concept  from  the  LRU  is  retained,  although  the  intent  of  IMA 
architectures  is  to  eo-loeate  many  LRMs  in  a  eentral  loeation  (advantageous  to  the  design 
of  the  aireraft)  and  link  them  upon  a  shared  baekplane.  Connectivity  to  the  distributed 
sensors  and  effectors  is  provided  by  Ethernet-based  fiber-optic  cable  network.  The 
arehiteeture  allows  for  what  European  researehers  Mirko  Jakovljevie  and  Astrit  Ademaj 
deseribe  as  “embedded  resouree  sharing”  (2013,  p.  7D5-1).  In  addition  to  the  SWAP 
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benefits  of  sueh  an  arrangement,  they  also  assert  that  IMA  “supports  design  of  new 
integrated  functional  capabilities  which  could  not  be  implemented  in  a  federated  system.” 

Given  the  real-time  (or  near-real-time)  performance  requirements  present  in  many 
aircraft  avionics  and  mission  systems,  time-partitioning  of  some  order  determines  the 
extent  to  which  resource-sharing  can  be  applied.  Effective  time -partitioning  provides  for 
efficient  multi-tasking  with  deterministic  Quality  of  Service  (QOS)  provided  to  all 
concurrent  processes.  In  absence  of  adequate  prioritization  controls  (including  memory), 
a  shared  processing  environment  might  allow  multiple  low-or-medium-priority  functions 
to  dangerously  draw  resources  away  from  the  smaller  subset  of  mission-critical  or  safety- 
of- flight  functions. 

The  issue  of  adequate  time-partitioning  and  guaranteed  QOS  for  high  criticality 
functions  led  to  the  development  of  the  ARINC  653  standard,  initially  released  in  1996 
(as  a  joint  project  of  Boeing  and  AEEC).  This  specification  describes  a  Real  Time 
Operating  System,  with  associated  Application  Executive  (APEX)  and  Application 
Programming  Interface  (API).  The  API  calls  for  51  routines,  allowing  time  and  space 
(memory)  partitioning,  health  monitoring  (error  detection  and  reporting),  and 
communications  via  “ports.”  (IEEE,  2008,  p.  14).  Individual  APIs  have  been  developed 
for  both  C  and  Ada  languages,  to  allow  use  in  both  military  and  civil  applications. 

With  ARINC  653  providing  for  deterministic  cross-functional  resource-sharing, 
another  standard,  ARINC  664  describes  the  way  nodes  within  the  network  are  connected. 
Also  known  as  AEDX  (Avionics  Pull-Duplex  network),  ARINC  664  is  a  profiled, 
switched  Ethernet-based  network  standard  for  high-speed  digital  avionics 
communications.  Utilizing  these  two  standards  together,  IMA  architecture  was 
implemented  by  Airbus  in  the  A380  passenger  liner.  As  described  by  Jakovljevic  and 
Astrit  Ademaj,  the  system  “replaces  multiple  LRUs  by  a  smaller  number  of  more  generic 
Core  Processing  and  Input  Output  Modules  (CPIOMs)  integrated  into  an  Avionics  Bay 
sharing  the  power  supply  and  the  communication  connection.”  (Jakovljevic  &  Ademaj, 
2013,  p.  7.B.5-2)  The  CPIOMs  consist  of  a  physically  distinct  CPU  (running  AEDX)  and 
various  I/O  modules  (all  implemented  as  LRMs)  that  provide  tailored  interface  with 
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various  peripherals  serviced  by  the  module  (IE:  sensors,  displays,  control  actuators,  etc.). 
The  CPIOMs  are  coimected  via  a  star-topology  AFDX  network.  (See  Figiue  1). 


Acluejtors/ 


Sensors. 


Figiue  1.  Airbus  A380,  domain-based  IMA 
(from  Jakovljevic  &  Ademaj,  2013) 


Apparent  from  this  description:  resomce-pooling  in  the  Airbirs  A380’s  IMA 
architecture  is  not  system-wide.  The  nimrber  of  stove-pipes  has  been  greatly  reduced 
however  by  incorporating  many  individiral  fimctions  into  just  three  sirbsystem  domains: 
“cockpit  (electrical  flight  control,  cormnimicatiorrs  and  warning);  cabin  (air  conditioning 
and  pneumatics);  and  utilities,  including  energy,  friel  fimctions  and  landing  gear 
fimctions.”  (Ramsey,  2005)  Rockwell-Collins,  the  firm  that  designed  the  system  claims 
that  100  imiqire  LRUs  were  eliminated  as  a  result  of  fimctional  integration  (Mairaj  & 
Tahir-,  2014,  Table  4). 

A  somewhat  more  aggressive  application  of  the  IMA  pr-incipals  can  be  foimd  in 
the  Boeirrg  787  “Dreamliner.”  Rather  than  domain-based  partitioning  of  computing 
resoiu'ces,  the  787’s  architecture  implements  a  Common  Core  Systems  Approach  (CCS), 
where  the  entire  spectnrm  of  assigned  domains  is  serviced  by  a  single.  Common 
Computing  Resoiuce  (CCR)  consisting  of  multiple  General  Processing  Modules  (GPM)  - 
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which  are  all  identical  LRMs  -  and  a  minimal  number  of  Application  Specific  Modules 
(ASM)s  linked  via  an  AFDX  backplane.  (See  Figure  2.) 

The  key  enabler  of  this  and  other  EMA  systems  is  the  distributed  network  of 
standardized  Remote  Data  Concentrators.  RDCs  act  as  a  coimection  point  where  discrete, 
or  analog  signals  fiom  I/O  peiipherals  are  converted  for  tiansmission  within  the  AFDX 
Ethernet  network.  They  are  located  in  close  physical  proximity  to  the  sensors  or  other 
devices  they  seiwe,  and  one  RDC  can  seiwe  as  may  devices  as  its  ports  and  processing 
capacity  allow.  This  eliminates  the  signal  corruption  issue  of  sending  non-digital 
infoimation  across  long-transmission  lines,  and  combats  latency  by  off-loading  the 
signal-conversion  task  fiom  the  centralized  CCR.  (Jakovljevic  &  Ademaj,  2013,  p.  7D5- 
5).  Of  note,  RDC’s  will  also  allow  the  re-use  of  older  digital  devices  designed  for  the 
legacy  ARINC  429  network,  if  such  is  desired.  (For  DOD  Applications,  were  weapon 
systems  have  long  been  standardized  rmder  MIL-STD-1553B,  the  rrse  of  srtch  RDC’s  is  a 
vital  enabler  for  Integra tiorr.) 


Figrtre  2.  Boeing  787.  CCS-based  IMA  (fiom  Jakovljevic  &  Ademaj,  2013) 

According  to  Boeirrg  press  reports,  system  engineers  on  the  787  were  able  to 

integrate  80  different  fimctions — fiom  anti-icing  systems  to  passenger  Internet  access — 

while  at  the  same  time,  eliminating  over  a  hrmdred  rmiqite  LRUs.  (Ramsey,  2005) 

Fruthermore,  data  firsion  and  sharing  across  domains  allows  for  enhanced  on-board 
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diagnostics,  event-logging,  and  maintenanee  reporting.  Flight  erews  are  provided  with 
Eleetronie  Flight  Bags  (EFBs)  whieh  are  fully  tied  into  the  aireraft’s  navigation 
equipment  and  displays  and  eommunieation’s  suite.  In  other  words,  the  aircrafts  avionics 
system  is  now  eapable  of  performing  mueh  of  the  integration  and  proeessing  feats  that 
pilots,  flight  engineers  and  maintenanee  personnel  previous  had  to  do  themselves  in 
eonverting  data  to  information  to  understanding,  and  finally,  to  action. 

5.  Military  IMA 

The  development  of  IMA  arehiteetures  has  not  been  eonfined  to  civil  aviation. 
The  F-22  Raptor’s  avionies  architecture  was  built  along  a  domain-based  IMA  approaeh 
that  teehnieahy  predated  that  used  in  the  Airbus  A380.  The  aireraft  features  two  separate 
Common  Integrated  Proeessors  (CIPs)  to  provide  eentralized  eomputing  resourees,  split 
aeross  three  funetional  domains:  Mission  Management,  Sensor  Management,  and 
Vehiele  Management.  (Spitzer,  2001,  Chapter  32)  Eaeh  CIP  is  aetuahy  a  eluster  of 
individual,  modular  proeessing  units,  with  identieal  form-faetor,  but  differing 
eapabilities.  Seven  different  types  are  employed  to  control  the  full  set  of  domain 
funetions.  Up  to  66  of  these  proeessing  eards  ean  be  installed  in  eaeh  self-eontained  CIP 
raek,  but  currently  19  slots  remain  open  in  CIP  #I  and  22  are  unused  in  CIP  #2,  allowing 
for  future  growth.  Provisions  were  made  within  the  airframe  for  the  installation  of  a  third 
CIP,  should  that  beeome  neeessary  (Eoekheed-Martin,  ND). 

Mueh  of  the  proeessing  power  of  the  F-22  (and  other  modem  taetieal  aireraft)  is 
dedicated  to  presenting  high-fidelity,  graphic -intensive  eoekpit  displays  to  the  pilot.  MIF- 
STD-1553  data  busses  offered  inadequate  throughput  for  sueh  data-heavy  applieations; 
indeed,  fourth-generation  fighters  with  glass  eoekpits,  sueh  as  the  F-16  and  F-18,  had 
been  foreed  to  rely  upon  a  patehwork  of  multiple  1553  busses  to  aehieve  the  neeessary 
eapaeity.  (Kopp,  2001)  At  the  same  time,  the  newer,  faster,  fiber-based  1553  standard 
(MIF-STD-1773)  did  not  offer  the  deterministie  isoehronous  performanee  that  the  F-22 
design  team  needed  in  order  to  integrate  time-eritieal  functions  into  the  eommon  avionies 
network.  At  the  time,  ARINC  653  (AFDX)  was  still  in  development  (by  Airbus),  and 
Foekheed  deeided  to  go  with  another  emerging  standard:  IEEE  1394,  better  known  by  its 
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consumer-electronics  trade  name  “Firewire.”  This  solution  provided  the  necessary 
performanee  and  charaeteristics  but  has  not  aehieved  any  wide-spread  use  in  other 
aircraft  besides  the  F-22.  Subsequent  developments  of  IEEE  1394  have  demonstrated  that 
gigabit  transfer  rates  are  possible  (Baltasar  &  Chapelle,  2001,  p.  15),  and  it  may  yet 
emerge  as  an  important  standard  for  military  avionics,  but  enthusiasm  for  Firewire  seems 
to  have  eooled  in  the  last  deeade — perhaps  because  of  the  sueeess  of  AFDX  in  the  Airbus 
A380/350,  and  Boeing  787. 


F-4  Pantom 
F-15  Eagle 
F-16  Falcon 
F-18  Hornet 
V-22  Osprey 
F-22  Raptor 
Boeing  777 
Airbus  A380 
Boeing  787 


1950  1960 


•— 


1970  1980 


1990  2000  2010 


Program  Initiation  IOC 


Figure  3.  Timeline:  avionics  standards  versus  aircraft  technology  adoption 


B.  SIZE-WEIGHT-POWER  BENEFITS  OF  IMA 

With  the  recent  proliferation  of  IMA-style  avionics  in  commercial  aircraft,  it  has 
finally  become  possible  to  quantify  the  size-weight-and-power  reduetions  that  are 
typically  achieved  with  such  an  architecture.  A  2014  study  by  two  Pakistani  researehers, 
Aamir  Mairaj  and  Rohail  Tahir,  compiled  manufacturer-supplied  data  from  twenty-eight 
different  aireraft  to  determine  what,  if  any,  real  gains  had  been  realized.  A  few  of  these 
aircraft,  such  as  the  Boeing  787,  were  designed  from  the  ground-up  as  IMA  platforms  but 
had  a  history  of  very  similar  aircraft  from  which  to  draw  comparisons.  The  majority  of 
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study  subjects,  however,  were  aircraft  that  had  initially  been  equipped  with  federated 
systems,  and  then  later  upgraded  to  IMA.  The  results  demonstrated  conclusively  that  the 
logical  efficiency  of  deconstructing  the  domain-stovepipes  and  sharing  system  resources 
translates  into  very  real  SWAP  benefits.  (Mairaj  &  Tahir,  2014)  Select  data  from  the 
study  are  depicted  in  Table  1. 


Table  1.  SWAP  Benefits  for  IMA  (after  Mairaj  and  Tahir,  2014) 


PERCENTAGE  VOEUME  REDUCTION 

aircraft 

volume  reduced  % 

Boeing  777  ER 

50.0% 

Airbus  A3 80 

50.0% 

Rafale 

50.0% 

Cessna  Citation 

40.0% 

Challenger  60 1 

28.3% 

Falcon  20 

28.3% 

King  Air  350 

50.0% 

King  Air  300 

28.3% 

ERU  EEIMINATED 

aircraft 

number  eliminated 

Boeing  787 

100 

Airbus  A3 80 

100 

Embraer  170/190 

15 

Raytheon  Hawker 

13 

Challenger  60 1 

15 

Falcon  20 

15 

King  Air  350 

15 

ED  728 

14 

WEIGHT  REDUCTION 

aircraft 

weight  shedding  (lbs) 

Boeing  787 

2000 

Cessna  Citation 

300 

Embraer  170/190 

550 

Gulfstream  G350 

300 

Raytheon  Hawker 

341 

ED  728 

462 

Challenger  60 1 

500 

Falcon  20 

340 

King  Air  A3  50 

100 

King  Air  300 

348 

POWER  REDUCTION 

aircraft 

%  power  reduced 

Boeing  777  ER 

50 

Rafale 

60 

Challenger  60 1 

38 

Falcon  20/50 

38 

King  Air  350 

38 
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Mairaj  and  Tahir  summarized  their  results  as  follows:  “The  analysis  reveals  that 
in  all  these  projects  SWAP  efficiency  was  achieved:  a  size  reduction  ranging  28.28  %-50 
%,  a  power  reduction  ranging  38%-60  %,  and  a  weight  reduction  ranging  25  %-50  % 
was  attained.  Moreover,  the  transition  appears  to  be  more  advantageous  on  large-size 
aircraft”  (para.  V.). 

It  follows  intuitively  that  the  more  complex  an  aircraft  is  (in  terms  of  desired 
avionics  functionality)  the  more  opportunities  exist  for  component  integration  and 
resource-sharing;  thus  is  no  surprise  the  biggest  “gainers”  in  Mairaj  and  Tahir’s  survey 
are  the  large  airliners  (Boeing  and  Airbus)  and  the  multi-role  fighter  (Dassault  Rafale). 
Logically,  the  ratio  of  an  aircraft’s  dry,  empty  weight  to  the  weight  of  its  avionics 
systems  would  determine  what  sort  of  performance  gains  an  aircraft  might  see  from  a 
given  reduction  in  the  latter.  The  larger  the  ratio,  the  more  significant  the  effect. 

Medium-size,  multi-role  military  aircraft  (such  as  the  Rafale,  or  more  germane  to 
this  thesis,  the  FVL)  likely  have  the  highest  such  ratio  of  any  manned  platforms  flying 
today.  The  implication  is  that  this  class  of  machinery  stands  to  gain  the  most  by 
transitioning  to  an  advanced  integrated  architecture. 

C.  INTEGRATED  MODULAR  AVIONICS— GENERATION  TWO 

Despite  the  demonstrated  advantages  of  IMA-based  systems  and  the  clear  success 
of  the  Boeing  787,  the  Airbus  A380/A350,  there  is  ample  room  to  develop  follow-on 
architectures  that  move  beyond  these  first-generation  designs  and  achieve  even  greater 
SWAP  gains — primarily  through  extensive  virtualization.  In  an  ideal  Second-Generation 
Integrated  Modular  Avionics  (IMA2G)  system,  there  are  no  LRUs  or  even  physical 
ASMs.  (See  Figure  3.)  An  aircraft- wide  network  of  Common  RDCs  would  link  sensors 
and  effectors  to  the  digital  data  bus,  and  application  specific  software  modules — virtual 
ASMs — reside  and  carry  out  their  tasks  within  an  abstracted  environment  created  by  an 
avionics  “cloud”  of  GPMs.  The  total  aggregate  resources  of  that  cloud  would  be  available 
for  subdivision  into  any  imaginable  combination  of  requirements. 

It  should  be  emphasized  that  the  computing  and  memory  resources  of  the  avionics 
cloud  need  not  physically  be  located  in  a  central  location  within  the  aircraft.  In  a  civil 
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ailcraft.  they  almost  certainly  would  be,  simply  for  the  sake  of  practicality  and 
maximizing  passenger  and  cargo  space.  For  a  military  application,  where  resiliency 
against  battle  damage  and  tight  packaging  constraints  might  apply,  the  Centralized 
Computing  Resomces  might  actually  be  highly  decentralized  physically.  The  physical 
separation  of  processing  fiom  input/output  is  a  key  aspect  of  all  IMA,  but  especially  the 
proposed  second-generation  standard.  For  that  reason,  IMA2G  is  sometimes  referred  to 
(or  associated  with  the  concept  of)  Distributed  Modirlar  Electronics,  or  DME.  (Firchsen, 
2009) 


Figrrre  4.  IMA2G  -  Distribirted  Embedded  System  Virtualization 
(jfrom  Jakovljevic  &  Ademaj,  2013) 


IMA2G  encompasses  a  wide  range  of  technologies  and  approaches,  with  myriad 
potential  benefits.  Most  obvioirs  is  the  chance  to  build  fluiher  itpon  the  SWAP  and  life- 
cycle  cost  reductions  aheady  evident  where  first-generation  IMA  has  supplanted 
federated  systems.  More  significant  perhaps  in  the  long  term,  however,  is  the  opportunity 
to  change  the  way  aircraft  (especially  military  aircraft)  are  designed,  tested,  certified, 
operated,  maintained,  and  re-developed. 
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1,  Challenges 

Current  challenges  to  advanced  IMA  implementation  are  well-documented. 
(Jakovljevic  &  Ademaj,  2013;  Fuchsen,  2009;  Wolf,  2008,  etc.)  For  the  purpose  of  this 
study  we  will  focus  on  five  specific  areas: 

•  High-speed  networking — required  to  connect  distributed,  embedded 
processors. 

•  Multi-Core  processing — required  to  facilitate  high-performance  system 
demands. 

•  Secure  virtualization — to  enable  reliable  functionality  within  the  avionics 
cloud  and  defend  against  malicious  agents. 

•  Open  standards  software  integration — to  streamline  development. 

•  Model-based  development,  verification  and  certification — to  ensure  that 

the  right  system  is  built  for  the  requirements,  and  that  testing  and 
certification  delays  do  not  impede  system  life-cycle. 

D,  CURRENT  IMA2G  INITIATIVES 

1.  SCARLETT 

According  to  their  organizational  website.  Project  SCARLETT  is  a  European 
consortium  with  members  from  39  countries,  organized  under  the  auspices  of  the  EU’s 
7th  Eramework  Program  (PP7)  for  advancing  research  in  innovative  high-tech  fields. 
SCARLETT  is  said  to  stand  for  “SCAlable  and  ReconfigurabEe  Electronics  plaT forms 
and  Tools.”  Their  stated  goal  is  to  bring  about  the  next  generation  of  Integrated  Modular 
Avionics.  Since  2008,  they  have  been  perhaps  the  most  vocal  driver  of  research  in  the 
field.  Indeed,  the  term  IMA2G  used  throughout  this  paper  seems  to  have  been  coined  by 
this  group,  and  it  strongly  associated  with  them.  By  no  means,  however,  do  they  hold  a 
monopoly  on  the  concept.  SCARLETT  researcher  Rudolf  Euchsen  describes  the  bottom- 
line  of  what  they  seek  to  achieve  with  their  work:  “reduction  of  development  and 
maintenance  costs,  reduction  of  certification  costs  by  means  of  incremental  certification, 
reduction  of  energy  costs  and  an  increased  availability.”  To  that  end,  he  further  identifies 
seven  areas  of  focused  research.  (Compare  these  to  the  challenges  listed  in  the  prior 
section): 
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•  Separate  I/O  From  Computing  Modules. 

•  Support  Inereased  Computing  Performanee. 

•  Provide  Abstraetion  Of  Platform  Level  Serviees. 

•  Implement  Reeonfiguration  Meehanisms. 

•  Provide  Integrated  Proeesses  And  Tool-Sets. 

•  Teehnologieal  Survey  Of  Paekaging  Solutions. 

•  Support  Definition  Of  Assoeiated  Standards.  (Fuehsen,  2009,  p.  7.B.5-2) 

2.  FACE 

The  Future  Airborne  Capabilities  Environment  (FACE)  is  a  publie-private-seetor 
eonsortium,  organized  in  2010  for  the  express  purpose  of  defining  a  new,  open,  avionies 
standard  for  airborne  military  systems.  (The  Open  Group,  n.d.)”  EACE  Consortium 
members  are  a  “who’s  who”  of  the  U.S.  aviation  and  avionies  segment,  ineluding 
Eoekheed-Martin,  Boeing,  Bell  Helicopter,  Sikorsky,  Honeywell,  Rockwell-Collins,  etc. 
DOD  partners,  meanwhile,  include  Navy  Air  Systems  Command  (NAVAIR)  and  the 
Program  Executive  Office  (PEO)  for  Army  Aviation.  In  other  words,  EACE  appears  to 
have  the  both  the  resources  and  the  influence  to  truly  establish  a  broadly-supported 
standard  for  a  Modular  Open  Systems  Architecture  (MOSA).  Although  the  term 
‘TMA2G”  does  not  appear  in  the  group’s  self-promotion  materials,  their  espoused  goals 
of  developing  an  open,  modular,  standard  for  horizontal  and  vertical  software  interfaces 
in  military  identifies  them  as  part  of  the  same  trend-line.  Their  technical  standard  is 
currently  in  its  version  2.1  iteration,  and  divides  the  computing  environment  in  five 
layers:  Operating  System  Segment,  the  Input/Output  Services  Segment,  the  Platform- 
Specific  Services  Segment,  Transport  Services  Segment,  and  the  Portable  Component 
Segment. 

E.  EVE  PROGRAM 

In  October  2008,  the  Euture  Vertical  Eift  program  (EVE)  was  announced; 

covering  a  number  of  individual  development  efforts  aimed  at  bringing  the  next 

generation  of  military  helicopters  (or  helicopter-like  aircraft)  into  existence.  This 

19 


initiative  is  a  result  of  the  belated  realization  that  the  DOD’s  eurrent  fleet  of  vertical  lift 
aircraft  has  been  historically  under-developed  compared  to  fixed-wing  counterparts,  and 
will  not  meet  the  performance,  payload,  availability  and  survivability  metrics  required  for 
sustained  world-wide  Joint  Forces  operations.  Ultimately,  four  different  airframes  of 
varying  sizes  (light,  medium,  heavy,  and  ultra-heavy)  are  envisioned,  replacing  some 
4000  OH-58s,  OH-6s,  H-60s,  AH-64s,  CH-47s  and  H-53s  in  service  with  the  U.S.  Army, 
Navy,  and  Air  Force.  (Defense  Industry  Daily,  2013) 

1,  FVL  ICD:  Desired  Attributes  and  Outcomes 

A  draft  copy  of  the  Initial  Capabilities  Document  (ICD)  for  the  FVL  Family  of 
Systems  was  released  in  December  of  2011  and  finalized  seven  months  later  in  July 
2012.  Table  2,  below,  summarizes  the  desired  performance  parameters  listed  in  the  ICD, 
which  represent  an  order-of-magnitude  increase  over  what  current  DOD  rotorcraft  are 
capable  of.  Essentially,  Future  Vertical  Lift  aircraft  will  be  expected  to  fly  roughly  twice 
as  fast,  twice  as  far,  while  carrying  the  same  or  greater  payload.  (Jeffrey,  2012) 


Table  2.  Threshold/objective  performance  requirements  for  FVL  variants 

(after  USA,  2011) 


Speed  (cruise) 

Combat 

Radius 

Payload  (int/ext) 

Passengers 

JMR-Light 

230-300  kts 

265  nm* 

2,000-4,500  lbs 

4-6 

JMR-Medium 

230-300  kts 

265  nm* 

6,000-20,000  lbs 

11-24 

JMR-Heavy 

230-300  kts 

265  nm* 

16,000-30,000 

lbs 

33-44 

JMR-Ultra 

230-300  kts 

350  nm* 

40,000-72,000 

lbs 

100-120 

*Defined  as  “unrefueled  distance  w/2.0  hr  loiter  (full  combat  load  at  6k/95°  L)” 
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This  includes  an  emphasis  on  the  ability  to  operate  in  hot/heavy/high  conditions. 
The  combat  radius  listed  is  based  on  95°  F  day  at  6000  ft  pressure  altitude,  with  a  full 
eombat  load  and  a  two-hour  loiter  time  in  the  mission  area.  To  extend  that  further,  all 
variants  are  to  be  capable  of  aerial  refueling,  making  strategic  self-deployment  a  reality. 
Meanwhile,  to  ensure  survivability,  state-of-the-art  countermeasures  must  be  included  in 
all  airframes,  and  the  design  should  incorporate  lessons  learned  from  combat  losses  in 
Iraq  and  Afghanistan. 

Summarizing  FVL  requirements.  The  ICD  lists  the  following  as  desired  attributes 
and  outcomes: 


•  Range/Payload.  FVL  FoS  platforms  must  cover  greatly  expanded  JFOR 
areas  of  operation  in  worldwide  conditions  with  playloads  responsive  to 
mission  requirements. 

•  Flight  Performance  . . .  platforms  will  have  the  ability  to  minimize  transit 
time,  solve  mismatches  in  flight  eapabilities  of  vertieal  lift  assets,  enable 
time-critical  MEDEVAC  missions,  conduct  maneuvering  flight  to  evade 
enemy  fires  and  operate  in  complex  terrain. 

•  Deployability  . . .  conduct  operational  maneuver  from  strategic  distances. 

•  Shipboard  Operation  ...  USN,  USMC,  USCG  and  SOE  EVE  EoS 
platforms  will  be  shipboard  compatible  . . .  USA  and  USAF  EVE  platforms 
will  be  shipboard  capable  ...  Operational  performance  shall  not  be 
degraded  by  electromagnetic  environmental  (E3)  effects. 

•  Weapons  . . .  capable  of  integrating  multiple  Joint  weapon  types  to  rapidly 
configure  for  volume  fire,  precision  and  area  effects  weapon  types  and 
mixes. 

•  Sensors  ...  employ  an  array  of  multi-speetral,  multi-function  sensors  ... 
fully  integrated  with  targeting,  navigation,  and  aircraft  survivability 
equipment  to  effectively  target  and  enable  terrain  flight  during  night  and 
in  Degraded  Visual  Environment  (DVE). 

•  Teaming,  Applicable  EVE  EoS  platforms  must  control  unmanned  systems 
up  to  Level  of  Interoperability  (LOI)  5.  Unmanned  or  optionally-piloted 
versions  of  FVL  variants  must  meet  Joint  interoperability  profiles  for 
Unmanned  Aircraft  System  (UAS)  Ground  Control  Stations  (GCS). 

•  Enhanced  Situational  Awareness  ...  provide  an  integrated  common  air 
and  ground  picture  to  the  pilots  and  crew,  with  automatic  reporting  ... 
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[internal  and  external]  ...  of  threats,  inelement  weather,  and  other  hazards 
eneountered  enroute. 


•  Crew  Station  . . .  provide  a  fully-integrated  erew  station  enabling  mission- 
focused  operations  [and]  Joint  mission  planning  systems  compatibility, 
automation  of  critical  battle  tasks,  cognitive  aiding  and  decision  making, 
fused  sensor  imagery,  and  interoperable  communications/data  systems  ... 
minimizing  crew  workload.  FOS  platforms  will  also  provide  decreased 
cold  start  and  airborne  times. 

•  NetCentric  ...  comply  with  the  provision  of  the  Net  Ready  Key 
Performance  Parameter  (NR-KPP)  per  CJCSI  6216. OIF.  Sensor  data  ... 
will  be  fully  compatible  with  the  Future  Mission  Network  (FMN) 
environment.  Joint  Service  air/ground,  allied,  civilian  (law  enforcement- 
LE  and  maritime),  mission  command  systems,  to  include  the  DOD 
Information  Enterprise  Architecture  (lEA)  and  DODI  8320.02.”  (U.S. 
Department  of  the  Army  [USA],  2011,  p.  3) 

Naturally,  in  keeping  with  today’s  highly  contentious  budgetary  climate,  all  of 
these  enhanced  capabilities  are  to  be  delivered  along  with  reduced  maintenance/operating 
costs,  increased  reliability,  extended  service-life  and  a  high  degree  of  component 
commonality  between  all  EVE  variants,  including  an  open-systems,  modular  mission- 
systems  suite. 

2,  Joint  Multi-Role  Technology  Demonstrator 

In  an  attempt  to  reduce  the  technological  risk  of  developing  an  entire  family  of 
aircraft  at  once,  the  DOD  has  established  a  precursor  program  focusing  on  the  medium 
lift  platform.  The  Joint  Multi-Role  Technology  Demonstrator,  (JMR-TD)  is  a  competitive 
development  program,  funded  and  administered  by  the  Army  PEO  for  Aviation.  Several 
prototype  middle-weight  EVE  contenders  will  be  sourced  from  different  manufacturers, 
and  evaluated  for  performance  potential  and  technological  maturity.  The  winner  (or 
winners)  will  then  be  awarded  follow-on  contracts  to  build  aircraft  for  the  Eight, 
Medium,  Heavy,  and  Ultra-Heavy  classes  within  the  EVE  Eamily  of  Systems,  using  the 
technology  explored  in  their  middle-weight  proof-of-concept. 

At  the  time  of  this  writing,  the  nine  initial  industry  proposals  have  been  down- 
selected  to  four.  Boeing-Sikorsky’s  concept  builds  upon  the  compound-helicopter 
architecture  developed  for  their  X-2  demonstrator  vehicle;  AVX’s  proposal  is  a  variation 
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on  the  same  theme,  with  twin-dueted  fans  supplanting  a  single  pusher  tail  rotor. 
Meanwhile,  both  Bell  Helicopter  and  Karem  Aircraft  are  developing  advanced  tilt-rotor 
platforms  that  they  hope  will  be  scalable  and  address  some  of  the  operational  limitations 
or  shortcomings  of  the  similarly-configured  V-22  Osprey.  What  all  designs  seem  to  have 
in  common  is  multi-mode  flight  operation  that  will  make  fly-by-wire  control  a  virtual 
requirement — a  technology  that  is  still  novel  among  rotary-wing  aircraft. 

In  the  event  it  is  determined  that  no  single  platform  can  successfully  be  scaled 
across  all  weight  classes  and  still  meet  performance  requirements,  more  than  one  concept 
may  be  accepted.  Regardless  of  the  aircraft  layout  however,  all  FVL  aircraft  are  to  feature 
a  common,  avionics  architecture.  Clearly,  this  will  require  a  flexibility  that  would  be 
difficult  or  impossible  to  achieve  with  a  traditional  federated  systems  model. 

The  requirement  for  a  common  avionics  architecture  is  a  reflection  of 
supportability  as  a  major  emphasis  area  within  the  FVL  program.  Expected 
characteristics  include  “the  ability  to  increase  the  service  rate  for  aviation  mission 
requests  without  expanding  force  structure,  [...]  open  systems  architecture  [...]  reduce 
fuel  consumption  and  logistics  footprint,  share  common  training,  education  and 
equipment  across  the  Joint  VTOL  fleet.”  (U.S.  Department  of  the  Army  [USA],  2011,  p. 
1) 

Initial  Operating  Capacity  (IOC)  for  the  FVL-medium  lift  variant  is 
conservatively  set  at  2035,  allowing  apparently  ample  time  for  cutting-edge  technology  to 
develop  and  mature.  FVL  contenders  are  expected  to  be  flying  prototype  JMR  airframes 
by  mid-2017. 

After  the  initial  phase  of  competition,  which  will  be  focused  on  aircraft 
performance  deliverables  concludes.  Phase  II  will  pick  up,  with  evaluation  of  aircraft 
avionics  and  mission  systems.  This  portion  is  considered  a  semi-independent 
development  effort,  complete  with  its  own  program  name:  The  Joint  Common 
Architecture.  A  Broad  Area  Announcement  (BAA)  was  issued  for  the  JCA  in  March  of 
2014.  In  June  of  the  same  year,  development  contracts  were  awarded  to  Boeing  and 
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Honeywell  to  build  demonstrator  modules  to  prove  the  feasibility  of  open-systems 
software  arehiteeture  in  an  IMA  environment. 

Given  that  nearly  all  of  the  major  industry  players  involved  in  the  FVL  and  JCA 
programs  also  happen  to  be  members  of  the  FACE  eonsortium,  FACE  standards  are 
likely  to  figure  prominently  in  the  arehiteeture  that  eventually  emerges. 

F.  BOEING  JOINT  COMMON  ARCHITECTURE  STUDY 

Within  the  Sikorksy-Boeing  EVE  team,  Boeing  will  likely  take  the  lead  role  in 
avionies,  mission-system  and  VMS  development.  The  Seattle-based  eompany’s 
experienee  with  the  highly  integrated  arehiteeture  of  the  787  airliner,  lends  eredibility  to 
their  efforts  and  suggests  that  some  sort  of  advaneed  IMA  arehiteeture  will  find  its  way 
into  their  EVE  design.  The  author  of  this  study  eondueted  an  interview  in  September 
2014  with  Tom  Dubois,  JMR/EVE  chief  systems  architect  at  Boeing’s  military  aircraft 
division,  and  gained  some  detailed  insights  on  the  program.  Most  relevant  perhaps  to  this 
thesis  is  the  fact  that  no  firm  decision  has  been  made  on  the  customer  side  about  the 
extent  to  which  current  IMA  trends  toward  virtualization,  centralized  processing,  and 
distributed  real-time  embedded  systems  will  be  incorporated  into  the  Joint  Common 
Architecture.  The  ICD  and  other  government  documents  only  describe  the  capabilities 
sought,  not  the  means  by  which  they  should  be  achieved.  The  challenge  for  Boeing  and 
other  contractors  is  to  strike  a  balance  between  accomplishing  the  DOD’s  ambitious 
objectives  on  one  hand,  and  yet  not  going  further  with  novel  technology  than  their 
customer  is  comfortable  with. 

Du  Bois  was  able  to  confirm  that  Boeing  is  indeed  pursuing  an  approach  that  will 
blur  the  line  between  electronics  and  the  air  vehicle  itself  In  their  concept,  the  JCA  will 
definitively  cross  over  into  domains  traditionally  considered  vehicle  management,  IE: 
“Things  that  touch  the  flight  controls.”  Beyond  addressing  size-weight-and-power 
concerns,  achieving  this  level  of  integration,  Du  Bois  believes,  will  help  facilitate  the 
desired  level  of  interoperability  and  interchangeability  between  manned  and  unmanned 
EVE  variants.  (T.  Du  Bois,  personal  communication,  September  25,  2014).  He  also 
expressed  confidence  that  advances  in  technology  will  allow  the  data-rates,  processing 
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and  through-put  necessary  for  highly-centralized  processing.  “For  the  foreseeable  future,” 
he  explains,  “there  is  still  going  to  be  a  need  for  some  form  of  data  concentration”  -  IE: 
Remote  Data  Concentrators,  to  perform  translation  and  network  gateway  functions  for 
devices  on  the  periphery  of  the  network  that  may  not  be  directly  compatible. 

1.  What  Is  the  Joint  Common  Architecture? 

It  is  easy  to  misunderstand  exactly  what  Boeing-Sikorsky  and  competitors  at  Bell 
and  Honeywell  are  trying  to  create  in  response  to  the  JCA  BAA.  “No  one  is  going  to 
build  a  JCA  for  the  FVL,”  explained  Dubois  (T.  Du  Bois,  interview,  September  25, 
2014).  That  is  because  the  JCA  is  not  intended  to  be  a  specific  set  of  hardware.  Rather, 
the  intent  is  to  prove  that  an  open-systems  architecture,  based  perhaps  on  FACE  technical 
standards,  can  enable  a  cost-efficient,  modular  approach  to  developing  and  fielding 
hardware  and  software.  According  to  the  Boeing  system’s  architect: 

•  The  JCA  is  functional  decomposition 

•  The  JCA  is  referential,  conceptual 

•  The  JCA  applies  “IMA  at  its  very  highest  levels” 

•  JCA  is  more  guidance  then  blue-prints 

•  JCA  encompasses  system-developer  tools 

•  JCA  utilizes  FACE  open  technical  standards 

•  JCA  is  to  be  nominally  owned  by  the  Gov’t,  while  FACE  belongs  to  the 
industry 

If  the  JCA  achieves  its  goals,  the  software  developed  to  run  on-board  systems 
will  be  completely  agnostic  from  the  underlying  hardware  and  platform.  This  offers 
several  potential  benefits  from  the  perspective  of  aircraft  life-cycle  costs. 

•  Software  re-use  across  different  aircraft  types  could  streamline  capability 
acquisition  while  ensuring  seamless  inter-operability. 

•  Hardware  re-purposed  throughout  a  single  aircraft  or  across  multiple 
aircraft  reduces  development  costs  and  shrinks  logistical  footprint  required 
to  maintain  deployed  aircraft. 
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•  Software  development  independent  of  vendors  aeeess  to  the  aetual  system 
hardware,  promotes  a  eompetitive  design  environment,  potentially 
lowering  eosts  and  aeeelerating  new  eapability  development. 

G.  SUMMARY 

The  teehnologieal  landseape  of  aireraft  avionics  has  progressed  to  a  state  probably 
unimaginable  to  early  pioneer  aviators.  As  complexity  and  costs  have  increased,  several 
successive  strategies  have  been  implemented  to  improve  efficiency.  The  latest.  Integrated 
Modular  Avionics,  seems  poised  to  progress  to  a  new,  second-generation  standard 
(IMA2G)  which  will  incorporate  unprecedented  levels  of  resource-sharing  and  systems 
integration,  while  simultaneously  permitting  tailored  physical  distribution  of  computing 
assets  as  dictated  by  form-factor  and  survivability.  In  this  chapter,  we  have  explored  the 
evolution  of  this  technology,  identified  the  remaining  technical  challenges  to 
implementation,  and  introduced  the  context  within  which  the  rest  of  this  study  will 
proceed:  the  application  of  advanced  IMA  to  the  Future  Vertical  Lift  Family  of  Systems. 
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III.  METHODS 


A.  COMPARATIVE  ANALYSIS 

The  impact  of  pursuing  highly  integrated,  software-defined  avionics  architecture 
for  the  Future  Vertical  Lift  Family  of  Systems  is  certain  to  be  as  multi-facetted  and 
complex  as  the  proposed  system  itself  In  order  to  begin  this  assessment,  a  divide-and- 
conquer  approach  will  be  applied,  conducted  on  two  separate  levels:  technological 
maturity,  and  suitability/alignment. 

1,  Technology  Maturity  Assessment 

We  will  model  this  portion  of  the  study  on  the  framework  provided  by  the  latest 
(2011)  version  of  the  DOD’s  Technology  Readiness  Assessment  (TRA)  Deskbook,  as 
prepared  by  the  Assistant  Secretary  of  Defense  for  Research  and  Engineering 
(ASD(R&E))  Table  3.  is  derived  from  paragraph  2.4.1  of  that  document,  and  provides  a 
template. 

Table  3.  Skeletal  Template  for  TRA  (from  Assistant  Secretary  of  Defense 
for  Research  and  Engineering  [(ASD(R&E))],  2011,  para.  2.4.1) 

1,0  Purpose  of  This  Document 

2,0  Executive  Summary 

3,0  Program  Overview 

3 . 1  Program  Obj  ective 

3.2  Program  Description 

3.3  System  Description 

4,0  Program  Technology  Risks  Summary  and  Readiness  Assessment 

4.1  Process  Description 

4.2  Identification  of  Technologies  Assessed 

^  ^  PM’s  and  SME  Team’s  Assessments  of  Technology  Risk  and  Technology 
Demonstration  in  a  Relevant  Environment 

4.3.1  First  Technology 

4.3.2  Next  Technology 

5,0  Summary _ 
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Referencing  previous  chapters  of  this  thesis,  the  reader  should  be  satisfied  that  the 
intended  purposes  of  sections  1.0  through  3.3  of  the  TRA  Deskbook  template  have  been 
adequately  accomplished.  The  present  chapter,  likewise,  will  accomplish  the  work  of 
section  4.1,  “Process  Description,”  and  4.2,  “Identification  of  Technologies  Assessed.” 
Given  that  advanced  IMA  is  a  broad  field  with  many  dependencies,  our  TRA  will  be 
broken  down  into  the  major  challenge  areas  previously  listed  in  Chapter  II  of  this  study: 

•  High-speed  networking 

•  Multi-Core  processing 

•  Secure  virtualization 

•  Open  standards  software  integration 

•  Model-based  development,  verification  and  certification 

Within  each  subject  area,  we  describe  the  need,  list  the  primary  issues  or 
difficulties  involved,  and  survey  recent  or  on-going  developments.  To  fulfill  the  role  of 
Subject  Matter  Experts  (SME) — as  called  for  the  TRA  methodology — several  JCA- 
program  insiders  have  been  interviewed  and  polled  for  their  technical  opinions.  In 
addition,  a  variety  of  published  sources  have  been  considered,  including  both  peer- 
reviewed  journal  entries,  and  vender  press-releases,  were  appropriate. 

The  assessed  maturity  level  of  each  identified  component  of  IMA2G  will  be 
expressed  as  integer  on  the  standard  Technology  Readiness  Level  (TRL)  scale,  (see  Table 
4.).  A  more  complete  chart  (After  ASD(R&E),  2011,  para.  2.5)  with  descriptions  and 
supporting  details  for  each  TRL  is  included  in  Appendix  B. 


28 


Table  4.  TRL  Definitions  (after  ASD(R&E),  2011,  para.  2.5) 


TRL 

Definition 

1 

Basic  principles  observed  and  reported. 

2 

Technology  concept  and/or  application  formulated. 

3 

Analytical  and  experimental  critical  function  and/or  characteristic  proof  of 
concept. 

4 

Component  and/or  breadboard  validation  in  a  laboratory  environment. 

5 

Component  and/or  breadboard  validation  in  a  relevant  environment. 

6 

System/subsystem  model  or  prototype  demonstration  in  a  relevant  environment. 

7 

System  prototype  demonstration  in  an  operational  environment 

8 

Actual  system  completed  and  qualified  through  test  and  demonstration 

9 

Actual  system  proven  through  successful  mission  operations. 

2,  IMA2G  and  FVL:  Suitability  and  Alignment 

We  will  first  apply  a  eomparative  analysis  of  documented  IMA  outcomes  and 
desired  FVL  attributes.  Referencing  the  previously  sighted  study  on  SWAP  reductions, 
along  with  other  sources  (including  interviews  with  FVL/JCA  insiders),  against  the 
approved  program  Initial  Capabilities  Document  (ICD),  this  portion  will  focus  on  the 
following  areas: 

•  Aircraft  Performance/Payload 

•  Mission  Capability/Flexibility 

•  Manpower/Training 

•  Development  Timeline 

•  Total  Life-Cycle  Costs 

•  Safety  and  Survivability 

•  Interoperability  with  UAS 
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For  each  area,  we  will  determine  to  what  extent,  if  any,  an  advanced  IMA  architecture 
would  support  achieving  the  desired  metrics.  Rather  than  attempt  to  extrapolate  predicted 
values,  only  the  basic  character  of  the  impact  will  be  assessed,  using  as  a  baseline  the 
likelihood  of  a  federated  systems  approach  achieving  those  same  results.  Ratings  will 
then  be  expressed  on  the  following  five-point  scale:  strongly  negative,  negative, 
neutral/indeterminate,  positive,  and  strongly  positive.  Owing  to  the  current  lack  of  a 
definitive  IMA2G  architecture  installation  aboard  an  operational  military  rotorcraft, 
specific  predictions  would  be  excessively  speculative  and  of  little  value.  The  scope  of  this 
part  of  our  inquiry  must  of  necessity  be  limited  to  a  single,  qualitative  assessment:  how 
much  does  the  DOD  stand  to  gain  by  incorporating  IMA2G-principles  into  its  next- 
generation  vertical-lift  aircraft? 

B,  SYNTHESIS  AND  PROJECTION 

With  the  maturity  level  of  IMA2G  technology  assessed,  and  the 
alignment/suitability  determined,  we  will  find  ourselves  in  position  to  develop  a 
meaningful  synthesis.  The  amalgamation  of  our  study  findings  will  be  expressed  in  two 
forms:  first,  a  risk-versus-reward  summary  of  applying  open- architecture,  software- 
defined,  highly-integrated  avionics  into  the  Joint  Common  Architecture  for  FVL;  and 
second,  a  projected  operational  vignette  depicting  how  a  cyber-physical  system  of  this 
kind  might  operate  in  a  plausible  future  combat  scenario. 

After  completing  this  synthesis  and  projection,  we  will  offer  our  final  conclusion. 
This  conclusion  will  include  recommendations  on  the  technical  architecture  the  DOD 
should  pursue  for  next-generation  rotorcraft,  controls  that  can  be  implemented  to  reduce 
the  inherent  risks  of  that  architecture,  and  finally,  further  research  that  should  be  done  to 
build  on,  or  validate  the  recommended  approach. 
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IV.  FINDINGS 


A,  CURRENT  CHALLENGES  TO  IMA2G  IMPLEMENTATION 

While  first-generation  IMA  arehiteetures  represent  the  eurrent  state-of-the-art  in 
aviation  today,  momentum  is  building  for  the  emergenee  of  true  IMA2G  systems. 
Though  elear  obstaeles  remain,  reeent  developments  represent  signifieant  inroads. 

1.  Limited  Data-Rates  and  Network  Throughput 

From  a  teehnieal  feasibility  standpoint,  the  areh-nemesis  of  eentralized  proeessing 
on  large  and  eomplex  aireraft  has  traditionally  been  the  rate  at  whieh  data  ean  be  traverse 
from  the  boundaries  of  the  system  (near  sensors  and  flight  eontrols)  to  the  shared 
eomputing  resourees  and  baek.  While  eritieal  flight  eontrol  funetions  generally  eonsume 
only  modest  volume  of  network  traffie,  their  low  toleranee  for  jitter  and  time-lateney 
require  eareful  handling.  Although  digital  data  bus  standards  have  evolved  to  supply  the 
requisite  quality  of  serviee,  that  task  is  inereasingly  eomplieated  by  the  trend  toward 
ever-greater  network  traffie.  The  advaneed  sensors,  external  data  links,  graphieal  eoekpit 
displays,  ete.,  expeeted  in  operational  aireraft  today  are  a  signifieant  ehallenge  to  legaey 
systems,  espeeially  eopper-based  standards  like  MIL-STD-1553B.  Advaneed  IMA2G 
systems  will  have  to  realize  mueh  higher  effeetive  throughput  to  ensure  eontinued 
performanee  over  their  intended  life-eyele. 

One  promising  teehnology  that  may  eontribute  is  Time-Triggered  Ethernet 
(TTEthemet).  This  standard,  first  deseribed  in  2005,  unifies  “realtime  and  non-real-time 
traffie  into  a  single  eoherent  eommunieation  arehiteeture”  (Kopetz,  Ademaj,  & 
Grillinger,  2005,  p.  1).  TTEthemet  is  essentially  three  protoeols  in  one,  with  differing 
levels  of  serviee  based  on  message-type:  Deterministie  Time-Triggered  (TT)  traffie. 
Event-driven  or  rate-eonstrained  (RC)  traffie,  and  Best-effort  (BE)  standard  Ethernet 
traffie.  TT  serviee  maintains  the  eloek  synehronization  for  all  deviees  attaehed  to  the 
network,  providing  for  a  “global  time  [that]  forms  the  basis  for  time-triggered  network 
properties  sueh  as  temporal  partitioning,  effieient  resouree  utilization,  parallel  proeessing 


and  preeise  diagnosties”  (Bisson,  201 1,  p.  5). 
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Essentially,  a  standard  Ethernet  serviee  provides  for  the  bulk  of  high-volume 
traffic  using  standard  message  formatting.  Event-driven  messages  take  advantage  of 
priority  handling,  (similar  in  principle  to  AEDX)  while  a  separate,  time-triggered 
function  periodically  takes  control  and  ensures  the  unfettered  transmission  of  sensitive 
real-time  data.  The  technology  was  originally  introduced  by  Austrian  vendor  TTTech, 
which  promised  fault- tolerant  deterministic  transmission  of  up  to  100  mpbs. 
Subsequently,  it  has  been  codified  as  SAE  standard  AS6802.  Now  multiple  vendors  can 
be  found  offering  PCI  form-factor  network  end-nodes  and  switches.  Total  advertised 
throughput  (for  TT,  RC  and  BE)  is  up  to  1000  Mbps. 

The  apparent  advantage  of  TTEthernet  over  other  “deterministic”  Ethernet 
protocols  (such  as  AXDX/  ARINC  664)  is  the  provision  for  a  baseline  of  standard  802.3- 
compatible  service.  Whereas  older  deterministic  solutions  like  the  ones  used  in  the 
Airbus  A380/250,  Boeing  787  and  Eockheed  E-22  are  essentially  proprietary  network 
standards  that  must  rely  on  network  gateway  devices  for  data-mapping  with  regular 
Ethernet,  TTEthernet  should  allow  seamless  connectivity  for  devices  not  requiring  real¬ 
time  service. 

Given  the  combined  attributes  of  high  bandwidth,  sub  millisecond  jitter-rate,  and 
IEEE  802.3  compatibility,  TTEthemet/AS6802,  seems  to  offer  a  workable  network 
backbone  on  which  a  distributed  real-time  avionics  environment  could  be  built.  Temporal 
synchronization  across  the  network  would  allow  for  parallel  processing  to  occur  across 
physically  separated  clusters  of  avionics  computers  -  making  an  aircraft  so-equipped 
more  resilient  to  battle-damage.  So-called  “temporal  firewalls”  (Bisson,  2011,  p.  5) 
could  be  automatically  instituted  at  the  switch  or  bus-control  level  in  the  event  of  a 
failure  in  one  or  more  processing  nodes.  Basically,  the  network  would  go  “deaf’  during 
the  time-partition  assigned  to  a  faulty  device. 

Despite  the  promise  of  TTEthernet,  our  research  has  uncovered  no  present 

examples  of  operational  military  or  civil  aircraft  utilizing  the  technology.  It  is  however, 

being  integrated  into  NASA’s  Orion  spacecraft,  (TTTech.com  News  &  Events,  2014) 

which  recently  completed  its  first  unmanned  test-flights.  Boeing  JCA  System  Architect 

Dr.  Tom  Du  Bois  also  confirmed  that  at  least  one  major  aircraft  development  program 
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that  he  is  aware  of  is  also  ineorporating  the  teehnology  (T.  Du  Bois,  personal 
eommunieation,  September  25,  2014).  Citing  eonfidentiality,  he  deelined  to  identify  the 
aireraft  or  the  manufaeturer.  With  regard  to  Boeing’s  own  efforts  to  develop  avionics  for 
the  FVL,  he  went  on  record  as  saying  that  time-triggered-Ethemet  “or  something  like  it” 
was  a  likely  candidate — but  no  decision  has  yet  been  made. 

It  should  be  noted  that  outside  of  aviation,  Time-Trigger  Ethernet  has  begun  to 
appear  in  production  hardware.  The  automobile  industry,  which  has  been  quietly  and 
effectively  developing  IMA-like  architectures  in  cars  since  the  early  2000s,  is  a 
significant  investor.  German  auto-giant  Volkswagen  has  partnered  with  the  originator  of 
TTEthemet  (TTTech)  through  its  Audi  subsidiary  (Plankensteiner,  2012,  p.  9).  The 
current  Audi  A8  sedan  incorporates  this  advanced,  deterministic  Ethernet  backbone  in 
order  to  facilitate  what  the  company  describes  as  “piloted  driving”  and  “piloted  parking,” 
which  is  to  say,  autonomous  operation  guided  by  a  distributed  network  of  integrated 
sensors  and  actuators  (Eehner,  2014). 

The  level  of  sophistication  and  safety-critical  reliability  required  of  cutting-edge 
automotive  systems  should  not  be  underestimated.  Rapid  product-development  cycles 
and  intense  competition  have  led  to  massive  advancements  and  highly-ambitious  goals. 
With  increasingly  stringent  government  and  consumer  expectations  for  fuel  economy, 
automotive  designers  have  found  themselves  battling  much  of  the  same  SWAP  concerns 
as  lead  aerospace  engineers  to  pursue  wide-spread  integration.  It  is  not  inconceivable  that 
the  industry  move  to  increasingly  connected,  increasingly  autonomous  automobiles  will 
make  it  a  larger  driver  of  cutting-edge  networking  and  processing  technology  than  the 
traditional  aerospace/defense  sectors  within  the  next  decade. 

a,  TRL  Assessment  for  TTEthemet 

Based  on  the  findings  of  this  study,  TTEthemet,  (AS6802)  should  be  considered  a 
rapidly-maturing  technology  with  the  ability  to  support  a  highly-integrated,  distributed 
IMA2G  architecture.  In  accordance  with  the  DOD’s  Technology  Readiness  Assessment 
(TRA)  criteria  (outlined  in  Chapter  III),  it  would  be  appropriate  to  say  it  has  achieved  a 
TRE  rating  of  6,  or  “System/subsystem  model  or  prototype  demonstration  in  a  relevant 
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environment”  (ASD(R&E),  2011,  para.  2.5).  The  system  prototype  in  question  being  the 
Orion  spaee-vehiele.  Given  the  extreme  operating  eonditions  inherent  to  orbital  spaee- 
flight,  and  the  suecessful  charaeterization  of  the  flight  test,  it  must  be  taken  that 
TTEthemet  has  demonstrated  some  ability  to  function  in  a  harsh  environment.  Naturally, 
the  eve’s  intended  environment  is  nothing  like  that  of  a  space  craft  and  may  introduce 
other  variables  (in  the  form  of  dust,  moisture,  or  battlefield  RE),  so  this  TRL  rating  must 
be  considered  tentative  as  far  as  application  to  the  Joint  Common  Architecture  is 
concerned. 

2.  Determinism  in  Multi-Core  CPUs 

Much  of  the  advances  that  have  been  made  so  far  in  digital  avionics  architectures 
have  been  enabled  by  the  exponential  growth  in  processing  power  available  from 
commodity  chip-sets.  In  the  last  decade,  most  of  that  growth  has  stemmed  from  the 
development  of  multi-core  processors,  yet  current-generation  avionics  have  yet  to  fully- 
embrace  this  technology.  There  has  been  debate  over  how  to  best  harness  the 
performance  advantages  of  multi-processing,  while  still  ensuring  strict  determinism  for 
high-criticality  safety-of-fiight  functions.  As  a  result,  even  the  most  advanced  IMAIG 
architectures  have  remained  reliant  upon  single-core  CPUs,  which  are  rapidly  becoming 
obsolete  as  a  commercial  technology.  Even  though  it  may  be  possible  to  implement 
1MA2G  without  the  support  of  multi-core  hardware,  as  a  minor  consumer  in  the  world¬ 
wide  marketplace  for  processors,  the  aircraft  avionics  industry  can  ill-afford  to  ignore  the 
market  trend  (Huyck,  2012).  Eurther,  there  is  no  doubt  that  the  performance  from  multi¬ 
core  processors  (MCPs)  would  greatly  facilitate  virtualization  of  resource-intensive 
applications. 

There  are  two  basic  ways  in  which  multi-core  CPUs  could  be  utilized;  Symmetric 
Multi-processing  (SMP)  and  Asymmetric  Multi-processing  (AMP).  In  SMP,  each  core 
within  the  CPU  works  concurrently  on  a  different  process  residing  within  a  single 
partition.  When  the  time  allotted  to  that  partition  expires,  the  processes  are  interrupted 
and  a  new  set  of  processes  from  the  next  scheduled  partition  are  distributed  to  the 
independent  CPU  cores.  In  AMP,  by  contrast,  each  CPU  core  works  on  a  process  (or  a 


34 


series  of  proeesses)  from  a  different  partition,  until  triggered  to  interrupt  that  work  and 
take  up  a  proeess  within  the  next  seheduled  partition.  As  its  name  implies,  Asymmetric 
multi-core  CPUs  may  contain  two  or  more  different  types  of  core,  optimized  for  various 
types  of  calculations;  whereas  the  individual  cores  within  symmetrical  multi-processors, 
are  identical  and  inter-changeable. 

Generally,  SMP  is  used  when  the  goal  is  over-all  computational  performance 
enhancement  -  true  multi-thread  processing  (Walls,  2014).  AMP  is  inherently  less 
efficient,  as  it  only  performs  concurrent  work  at  the  system  process  level;  however,  it 
allows  designers  to  run  an  RTOS  or  latency-sensitive  program  within  the  same  CPU  that 
is  simultaneously  running  a  lower-criticality  (but  perhaps  more  resource-intensive) 
process.  To  further  muddle  the  issue,  some  contend  that  real-world  performance  of  AMP 
systems  is  actually  the  same  or  better  than  SMP  when  many  cores  are  present  and  the 
scheduling  kernel  becomes  the  weak  link  (Hermeling,  2009).  This  is  because  process¬ 
scheduling  within  partitions  is  simplified  in  AMP  vis-a-vis  SMP;  IE;  only  one  process  is 
handled  at  a  time  from  a  given  partition. 

For  the  moment,  AMP  appears  easier  to  implement  with  the  current  version  of 
ARINC  653  standard,  as  memory  resources  shared  by  the  processing  cores  can  be 
apportioned  along  partition  lines,  avoiding  conflict  over  memory  address  locations 
(Huyck,  2012).  ARINC  653  has  no  mechanisms  to  subdivide  such  resources  within  a 
partition  according  to  the  number  of  cores  currently  splitting  the  work,  so  SMP  may 
result  in  concurrent  processes  competing  for  the  same  memory  resources. 

It  should  also  be  noted  that  some  advanced  multi-core  designs  may  combine  AMP 
and  SMP  to  balance  the  capabilities  and  trade-offs  of  each  (Walls,  2014).  In  such  an 
application,  a  specialized  multi-core  within  a  multi-core,  may  be  dedicated  to  AMP, 
while  an  array  of  identical  cores  on  the  same  chip  performs  SMP.  Such  hybrid 
architecture  seems  likely  to  proliferate;  thus  it  is  imperative  that  methods  of  integrating 
SMP  into  ARINC  653  (or  follow-on  standards)  be  investigated. 

In  May  of  2014,  the  Federal  Aviation  Administration  (FAA)  released  a  position 
paper  outlining  its  concerns  for  industry  adoption  of  multi-core  processors  for  safety- 
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critical  flight  operations.  The  paper  cites  features  typically  built  into  such  CPUs  that 
allow:  “shared  access  to  cache  or  other  memory  areas,  operating  systems  /  supervisors  / 
hypervisors  . . .  and  coherency  fabrics  /  coherency  modules  /  interconnects  that  control  all 
the  data  transfers  between  the  MCP  cores  ...  via  a  shared  bus.”  These  features  are 
asserted  to  have  resulted  in  observable  interference  between  applications  running 
simultaneously  on  different  cores  within  a  processor  during  testing.  The  report  goes  on  to 
say  that  “If  safety-critical  applications  are  to  successfully  execute  on  MCPs  [multi-core 
processors],  the  allowable  data  latency  of  each  input  parameter  to  an  application  may 
have  to  be  analyzed  so  it  is  ensured  that  the  applications  can  cope  with  the  worst  case 
variations  in  data  access  times,  which  should  be  measured.  The  overall  execution  times  of 
applications  may  have  to  include  allowances  for  such  variations”  (Federal  Aviation 
Administration  [FAA],  2014,  p.  4). 

Despite  this  and  other  noted  concerns,  the  FAA  paper  finally  provided  what  some 
in  the  industry  were  waiting  for:  a  roadmap  to  certification  for  multi-core  processor-based 
systems  consisting  of  24  quantifiable  objeetives  in  determinism,  software  and  error¬ 
handling.  Wind  River  Systems,  a  long-time  leader  in  RTOS  development  has  since 
announced  that  they  are  working  on  a  successor  to  their  suceessful  VxWorks653  OS 
(utilized  on  the  Boeing  787)  that  will  be  able  to  take  advantage  of  dual-core  silicon. 
(Wlad,  2014).  If  this  new  OS  follows  the  pattern  of  the  VxWorks  7Core  product,  an 
RTOS  already  certified  for  industrial  applications,  it  could  utilize  an  advanced  form  of 
SMP  that  gains  new  efficiency  by  allowing  idle  processes  to  be  handled  during  residual, 
unused  time  apportioned  to  the  active  proeess.  Wind  River  seems  confident  that  they  will 
be  able  to  deliver  this  capability  and  still  “ensure  reliable,  interference-free  consolidation 
of  multiple  applications  with  different  levels  of  safety  criticality  on  one  hardware 
platform”  sufficient  to  satisfy  government  regulators  (Wind  River  Systems,  2014). 

Independent  industry  experts,  such  as  David  Arterbum,  Director  of  Rotorcraft 
Systems  Engineering  and  Simulation  Center  at  the  University  of  Alabama  at  Huntsville, 
are  less-sanguine  about  the  short-term  prospects  of  multi-core  proeessing,  pointing  to  the 
difficulty  of  understanding  and  predicting  complex  interactions  within  quad-core  chips, 
which  are  rapidly  replacing  dual-cores  in  consumer  electronies.  Charged  with  compiling 
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the  studies  of  various.  Army  Aviation  PEO-funded  working  groups  researehing  JCA 
issues,  Arterburn  downplayed  the  significance  of  the  CAST-32  paper,  asserting  that  no 
multi-core  chip  installation  has  actually  achieved  official  airworthiness.  He  was  quick  to 
point  out  however  that  the  issue  will  soon  come  to  a  head.  “Within  five  years”  he 
predicted,  “you  won’t  be  able  to  buy  a  commodity  single-core  processor”  (D.  R. 
Arterburn,  personal  communication,  January  22,  2015).  Like  it  or  not,  industry  and 
government  will  soon  be  forced  to  develop  methods  of  designing  and  certifying  MCP- 
based  systems  -  and  that  event-horizon  is  sufficiently  near-term  that  it  will  likely  be  well- 
sorted  by  the  time  any  FVL  variant  is  ready  to  fly  in  anything  beyond  experimental 
status. 

In  the  meantime,  the  only  work-around  may  be  to  install  multi-core  processors 
and  then  intentionally  limit  them  to  single-core  utilization.  This  deals  with  the 
commercial  availability  aspect,  but  of  course  completely  defeats  the  point  of  having  an 
advanced  processor  to  begin  with.  It  also  works  against  the  very  principles  of  IMA, 
requiring  multiple  physical  LRMs  to  do  the  work  that  a  single,  fully-optimized  module 
could  do.  It  is  also  questionable  whether  simply  de-powering  all  but  a  single  processor  on 
a  chip  would  actually  make  it  legally  certifiable.  A  source  consulted  by  this  author,  who 
declined  to  go  on  record,  related  that  several  recently  introduced  aircraft  (including  an 
army  rotorcraft)  are  current  flying  with  partially-disabled  multi-core  processors  -  without 
any  real  declaration  or  sanction. 

a,  TRL  Assessment  for  Multi-Core  CPU  Employment  in  Avionics 

Based  on  the  finding  of  this  survey,  it  is  apparent  that  MCP-integration  is  a  hot- 
topic  in  the  aviation  and  avionics  industry  today.  Multiple  studies  are  underway,  but  both 
vendors  and  the  government  are  remaining  tight-lipped  on  the  results.  Given  the  lack  of 
demonstrated  success,  we  cannot,  in  good  faith,  assign  a  higher  TRL  than  4;  “Component 
and/or  breadboard  validation  in  a  laboratory  environment”  (ASD[R&E],  2011,  para.  2.5). 
Given  the  urgency  of  establishing  workable  protocols  and  methods,  we  are  confident 
however,  that  the  next  five  years  will  see  significant  advances.  Even  if  the  Joint  Common 
Architecture  must  be  demonstrated  in  prototype  form  without  the  use  of  MCPs  (or  with 
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partially-disabled  MCPs),  it  seems  fairly  likely  that  the  FVL  program  will  eventually  be 
able  to  leverage  them. 

3,  High-Assurance  Virtualization 

As  previously  noted,  extensive  virtualization  is  the  defining  eharaeteristie  of 
seeond-generation  IMA;  however,  there  is  still  debate  on  how  exaetly  to  best  implement 
that  hardware  abstraetion  for  high-eritieality  vehiele  management  funetions.  Currently, 
full  virtualization  is  the  approaeh  with  the  broadest  (non-aviation)  commereial  use.  In  this 
sehema,  one  or  more  eomplete,  unmodified  “guest”  operating  systems  run  atop  a 
hypervisor.  The  hypervisor  itself  may  have  direct  access  to  the  hardware  (in  a  so-called 
“bare  metal”  installation),  or  may  run  atop  another  operating  system  as  a  client  program. 
In  either  case,  the  virtualized  OS  has  no  idea  that  it  does  not  actually  have  access  to  its 
own  processor  and  memory.  Application-level  service  requests  from  its  processes  are 
passed  directly  to  the  real  hardware  by  the  hypervisor  (or  through  the  underlying  OS,  if 
present),  while  privileged-level  commands  from  the  guest  OS  are  intercepted  and 
translated  so  that  they  do  not  exert  unfettered  control  over  the  processor  and  memory 
resources  that  must  be  shared  with  other  guests. 

In  paravirtualization,  the  guest  operating  systems  are  installed  with  modified 
kernels,  making  the  OS  “aware”  that  it  does  not  have  direct  access  to  its  own  resources. 
Instead  of  issuing  un-executable  calls  that  must  be  trapped  and  translated  by  the 
hypervisor,  the  guest  OS  kernel  issues  hypercalls  that  reduce  virtualization  overhead. 
This  efficiency  has  a  positive  effect  on  performance,  but  the  downside  is  that  the  hosted 
OS’s  must  be  intrusively  altered  for  installation.  Though  this  is  easily  and  affordably 
accomplished  when  OS  source-code  and  vendor  support  is  available,  it  can  be  a  major 
obstacle  to  integrating  older  or  proprietary  OS’s  in  the  virtual  environment.  (Windows, 
for  instance). 

The  corresponding  downside  for  full-virtualization  is  that  hardware  requirements 
are  very  specific.  The  guest  OS  must  otherwise  be  able  to  run  atop  the  actual  underlying 
hardware.  Using  such  a  schema  in  an  IMA  architecture  would  seem  to  limit  the  choice  of 
processing  hardware  and  embedded  OS’s  to  those  that  were  natively  compatible  with 
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each  other.  (Most-likely  x86-series  processors.)  This  runs  completely  counter  to  the  idea 
of  using  IMA2G  to  affect  cost-savings  on  system  development  and  life-cycle  update.  It 
also  does  not  provide  compatibility  with  the  system  resource  partitioning  concept 
enforced  by  ARINC  653  (Fuchsen,  2009,  p.  7.B.5-6). 

The  present  trend  in  hardware  design  is  greater  built-in  support  for  virtualization, 
and  it  is  possible  that  this  will  eventually  allow  comparable  performance  increases  to 
paravirtualization  without  the  need  to  modify  the  hosted  operating  systems. 

In  the  meantime,  hardware  abstraction  in  the  current  IMA  architectures  relies  on 
paravirtualization.  In  the  Airbus  implementations,  this  is  provided  by  the  Virtual  Machine 
Monitoring  (VMM)  services  of  the  well-established  Pike  Operating  System.  Instances  of 
an  ARINC  653-standard  RTOS  run  in  the  abstracted  environment,  alongside  LINUX, 
POSIX  and  other  supported  open-source  operating  systems.  Similar  capabilities  are  also 
touted  by  the  makers  of  the  Lynx  OS  178  RTOS.  This  particular  product  is  claimed  to 
meet  FAA’s  DO-178B  Level  A  certification  standard  for  safety-critical  avionics  software 
“right  out  of  the  box”  (Lynx  Software  Technologies,  2015).  However,  it  should  be  noted 
that  since  the  introduction  of  this  RTOS,  the  FAA  has  introduced  an  updated  standard  - 
DO-178C  -  which  adds  five  additional  parameters  to  the  66  listed  in  -178B  for  “Level  A” 
certification.  There  is  no  indication  on  the  maker’s  website  that  Lynx  OS  178  RTOS  has 
met  these  revised  standards. 

a.  TRL  Assessment  for  High-Assurance  Virtualization 

High  assurance  paravirtualization  has  been  used  in  aircraft  avionics,  in  varying 
levels  of  criticality,  for  at  least  ten  years  now,  and  must  be  considered  a  mature 
technology,  or  TRL  9.  Some  SCARLET  consortium  researchers  (Jakovljevic  &  Ademaj  ) 
have  asserted  that  PIKE  OS  ‘s  Virtual  Machine  Manager  is  an  adequate  solution  to  the 
challenge  of  advanced  IMA2G  architectures,  while  others  (Kleidermacher  &  Wolf,  2008) 
contend  that  hardware-assisted  full-virtualization  will  likely  be  needed  to  deliver  fully  on 
the  promise  of  software  cost-savings  and  streamlined  re-development.  This  field 
however  is  far  less  mature,  with  a  TRL  level  as  low  as  3:  “Analytical  and  experimental 
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critical  function  and/or  proof  of  concept.”  Adhering  to  the  most  eonservative  viewpoint, 
we  will  aeeept  this  latter  assessment. 

4,  High  Robustness  virtualization 

The  threat  of  malieious  eyber-attaek  on  the  avionies  of  eommereial  aireraft  must 
be  eonsidered  a  legitimate  eoneem.  Indeed,  when  the  Boeing  787’s  IMA  arehiteeture  was 
announeed  to  the  general  publie  at  launch,  some  observers  wondered  openly  at  the 
wisdom  of  providing  passenger  Internet  via  the  same  physieal  eomputers  that  hosted  the 
aireraft  system  eontrols.  Was  this  not  introdueing  a  blatant  attaek  veetor  into  the  system? 
While  fears  that  a  determined  passenger  might  somehow  take  eontrol  of  an  airliner  with 
their  laptop  eomputer  are  eompletely  overblown  given  the  aetual  arehiteeture  of  the 
system,  the  basie  premise  is  not  without  merit  -  espeeially  when  one  eonsiders  the  further 
integration  of  VMS  funetions  in  proposed  IMA2G  aireraft.  For  military  aircraft,  whose 
mission-systems  will  host  applieations  of  differing  elassifieation  levels,  aehieving  strong 
security  compartmentalization  between  hosted  OSs  in  an  on-board  virtual  environment  is 
eritieal. 

Though  virtualization  has  often  been  touted  as  a  seeurity  measure  in  itself,  in 
reality  it  is  just  part  of  a  layered  defense  system  -  and  one  that  has  the  potential  to 
introduee  its  own  seeurity  vulnerabilities.  While  hosted  OS’s  might  indeed  be  isolated 
from  eaeh  other  and  have  restrieted  aeeess  to  system  resourees,  they  do  interfaee  with  the 
hypervisor.  If  the  hypervisor  eontains  exploitable  seeurity  flaws,  (let  alone  the  underlying 
OS  in  a  paravirtualized  seheme),  so-ealled  guest-breakout  is  possible.  Malieious  eode 
eould  easily  spread  from  one  guest  system  to  another,  or  take  over  the  entire  host 
eomputer  (Kleidermaeher  &  Wolf,  2008,  p.  l.C.3-5). 

The  most  often-proposed  remedy  for  achieving  what  the  Nation  Seeurity  Ageney 
(NS A)  deseribes  as  “High  Robustness”  in  a  multi-level  secure  arehiteeture  is  the  Multiple 
Independent  Levels  of  Security  (MILS)  concept,  first  deseribed  in  1984  by  noted 
eomputer  seientist  John  Rushby  (Parkinson  &  Baker,  2011).  A  MILS-type  arehiteeture  is 
based  on  two  high-eredibility  assertions:  I .)  A  software  eomponent  is  only  as  seeure  as 
the  layer  beneath  it.  For  virtual  computing,  that  means  that  if  the  VMM  or  hypervisor  is 
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not  secure,  than  none  of  the  hosted  VMs  are  secure.  2.)  The  smaller  and  simpler  a 
software  component  is,  the  fewer  vulnerabilities  it  will  contain,  and  the  easier  it  will  be 
for  developers  to  find  and  correct  those  vulnerabilities  prior  to  release. 

MILS-based  virtual  computing  environment  would  thus  employ  a  very  simple 
“micro”  separation  kernel,  functioning  as  a  bare-metal  hypervisor.  For  application  to  an 
aircraft’s  avionics,  this  hypervisor  would  also  have  to  be  optimized  to  support 
deterministic  real-time  processes  in  the  hosted  VMs.  (Small  kernel  size  and  real-time 
capability  are  not  mutually  exclusive  in  any  way;  if  anything,  they  tend  to  go  hand-in- 
hand.)  This  underlying  layer  would  contain  no  device  driver’s  specific  to  the  VM’s 
above  it,  keeping  it  simple  and  easier  to  certify.  It  would  be  designed  to  enforce  the 
following  security  policies  to  assure  that  system  events  (or  intrusion)  in  one  hosted  OS 
could  not  spread  laterally  or  upstream; 

•  Data  isolation,  which  ensures  that  a  partition  cannot  access  resources  in 
other  partitions 

•  Periods  processing,  which  ensures  that  applications  within  partitions 
execute  for  the  specified  duration  in  the  system  schedule 

•  Information  flow,  which  defines  the  permitted  information  flow  between 
partitions 

•  Fault  isolation,  which  means  that  a  failure  in  one  partition  does  not  impact 
any  other  partition  within  the  system  (Parkinson  &  Baker,  2011) 

With  that  in  mind,  paravirtualization  architecture  with  a  large  and  complex 
hypervisor  atop  an  ARINC  653  operating  system  (such  as  PIKE  OS  in  the  Airbus 
A380/A350)  would  probably  not  be  an  appropriate  choice  where  certified  “high 
robustness”  was  a  requirement.  Firstly,  the  large  size  of  the  kernel  would  make  it  difficult 
and  expensive  to  certify.  Furthermore,  the  inter-partition  communications  permitted 
under  ARINC  653  standard  may  create  violations  of  the  MILS  information  flow  policies 
that  protect  hosted  domains  of  differing  security  classifications.  (Kleidermacher  &  Wolf, 
2008,  p.  l.C.3-5).  Pike  OS’s  inclusion  of  complex  device  drivers  in  the  virtualization- 
layer  for  support  of  various  host-OSs  also  would  introduce  increased  certification 
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overhead;  eaeh  would  have  to  be  evaluated  to  the  same  standard  applied  to  the  most 
seeure  hosted  applieation  on  the  system. 

Various  alternate  solutions  have  been  proposed;  prominent  among  these  is  Green 
Hills  Software’s  Integrity  DO-178  RTOS,  a  miero-kernel-based  hypervisor  that  supports 
time/spaee/memory  partitioning  (with  no  dynamie  memory  alloeation)  for  safety-oritieal 
funetions  AND  eross-domain  seeurity  in  a  eommon  platform.  FAA-eertified  more  than  a 
deeade  ago  (lAW  the  older  DO-178B  standard)  for  use  aboard  the  Sikorsky  S-92 
helieopter,  the  maker  asserts  that  the  eurrent  version  of  the  software  has  sinee  aehieved 
the  official  blessing  of  the  NSA’s  NIAP  lab  as  a  “High  Robustness”  platform. 

Hardware  support  of  virtualization  also  interacts  with  achieving  a  balance 
between  robust  security  and  high  system  performance.  As  previously  described,  full 
virtualization  typically  offers  lower  performance  than  paravirtualization  due  to  increased 
virtualization  overhead;  but  full-virtualization  is  inherently  easier  to  make  secure 
according  to  the  MILS  paradigm.  The  consensus  view  seems  to  be  that  increasing  built-in 
support  for  virtualization  at  the  hardware  level  will  help  close  (or  even  reverse)  this 
performance  gap.  Furthermore,  Asymmetric  Multiprocessing  on  MCPs  inherently  offers 
an  additional  avenue  by  which  the  separation  kernel  could  maintain  the  integrity  of 
partitions.  Threads  from  VMs  of  differing  classifications  could  be  routed  to  different 
cores,  in  addition  to  the  separate  physical  memory  blocks,  with  little  or  no  performance 
penalty.  Integrity-series  software  by  Green  Hills  Software  provides  this  ability  when 
installed  on  MCP  devices.  The  advanced  SMP  performance  scheme  utilized  by  Wind 
River  Systems  in  their  VXworks  Core  7  product,  on  the  other  hand,  intermingles  threads 
from  different  partitions  during  cycle  slack-time.  This  inter-partition  resource  sharing 
would  have  to  come  under  close  control  and  scrutiny  to  assure  that  only  processes  from 
the  same  security-domain  level  would  share  a  core  during  a  given  cycle. 

a.  TRL  Assessment  for  High-Robustness  Virtualization 

The  most  extensively  flown  RTOS  VMM  (Pike  OS)  may  provide  adequate 
security  robustness  for  present-day  civil  applications,  but  in  a  world  of  increasingly 
sophisticated  cyber-aggression  that  may  not  always  be  the  case  in  the  future.  Certainly, 
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for  the  cross-domain  needs  of  a  sophisticated  war-fighting  platform,  it  is  not  appropriate. 
Fortunately,  a  MILS -architecture  compliant,  NSA-certified  micro-kernel  alternative  has 
already  achieved  operational  status  with  several  aircraft,  including  the  afore-mentioned 
S-92  helicopter  and  upgrades  to  the  B-2  and  F-16.  The  Green  Hills  Software  product  is 
also  being  incorporated  into  the  F-35  JSF,  where  its  virtualization  capabilities  are  being 
extensively  utilized.  This  fact  might  lead  one  to  assign  a  very  high  TRL  level  to  the 
technology;  but  our  conservative  approach  dictates  a  bit  more  caution.  The  F-35,  as 
advanced  as  it  is,  does  not  achieve  full  IMA2G-levels  of  integration,  virtualization  and 
distribution.  Although  Integrity  DO-I78B  is  likely  capable  of  supporting  that  type  or 
architecture,  we  have  uncovered  no  evidence  that  this  has  been  validated  outside  the 
laboratory  environment.  As  such,  we  will  restrict  our  rating  to  Technology  Readiness 
Level  4. 


5.  Open  Standards  for  Avionics-Grade  Military  Software 

The  goal  of  Integrated  Modular  Avionics  is  to  dismantle  the  functional  stove¬ 
pipes  that  have  historically  divided  the  complex  collection  of  avionics  systems  in  modern 
aircraft.  The  mismatch  of  software  interfaces  involved  though  makes  that  task  immensely 
more  difficult.  Besides  impeding  integration  and  interoperability,  the  reliance  on  single¬ 
platform,  proprietary  software  is  considered  a  major  cost-driver  within  military  aviation; 
and  there  is  no  reason  to  suspect  that  developing,  certifying  and  supporting  unique 
imbedded  software  will  ever  get  significantly  less  expensive.  If  anything,  increasing 
levels  of  complexity  make  the  opposite  effect  more  likely.  (Reference  the  NASA  study, 
cited  in  Chapter  I).  The  most  widely  prescribed  solution — supported  by  both  the  FACE 
and  SCARLETT  consortiums — is  the  development  a  common,  open-architecture  for 
aircraft  avionics.  Such  an  system  would  allow  “components  conforming  to  agreed-upon 
standards  to  be  added,  upgraded,  and  swapped”  and  “independent  parties  to  design  and 
develop  interoperable  components  that  work  together  under  the  specified  standards” 
(Hagen,  Hurt,  &  Sorenson,  2013,  p.  28).  It  would,  in  other  words,  be  an  application  of 
“form,  fit,  function”  on  a  logical,  as  well  as  physical  level. 
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The  idea  is  not  new.  According  to  Tom  Dubois  of  Boeing,  both  the  F-22  and  the 
ill-fated  Comanche  helicopter  programs  initially  hoped  to  leverage  some  sort  of  open- 
standard,  by  which  different  vendors  could  write  software  compatible  with  the  system 
and  drive  down  costs  through  competition.  In  the  time  frame  during  which  those  two 
projects  commenced  however,  there  was  no  existing  framework  that  would  offer  the  data- 
exchange  and  resiliency  capabilities  needed.  A  ground-up  standard  was  developed  -  with 
hopes  that  it  would  become  broadly  accepted.  Market  factors  and  security  concerns 
conspired  to  defeat  that  hope  however,  and  both  aircraft  ended  up  with  stove-pipes  of 
their  own  making  (T.  Du  Bois,  personal  communication,  September  25,  2014).  For  the 
Comanche,  the  cost  of  that  outcome  may  have  contributed  to  the  program’s  demise.  In 
some  ways,  the  difficulty  of  establishing  a  successful  open-standard  is  a  variation  of  “the 
chicken  or  the  egg”  problem;  a  new  product  may  not  be  successful  unless  it  is  compatible 
with  broadly-accepted  standards,  but  a  new  standard  cannot  find  broad  acceptance  unless 
multiple  products  are  built  upon  it.  Which  must  come  into  being  first?  The  product  (the 
“chicken”)  or  the  standard  (the  “egg”)? 

The  lessons  of  previously-unsuccessful  open-architecture  models  have  apparently 
not  been  lost  on  the  FVL  program.  The  Joint  Common  Architecture  initiative  is  an 
attempt  to  create  an  open-architecture  egg,  while  simultaneously  developing  an  entire 
flock  of  new  open-architecture  chickens  to  hatch  out  of  it.  Just  as  the  aircraft’s  physical 
architecture  is  supported  by  a  lobbying  consortium  of  government,  industry,  and 
academics  (The  FVL  Consortium),  its  avionics  development  has  a  symbiotic  relationship 
with  the  Future  Airborne  Capabilities  Environment  (FACE)  group. 

In  November  2014,  EACE-members  and  JMR-TD  partners  Boeing  and  Sikorsky 
concluded  a  four  month  feasibility  study  that  was  essentially  a  proof-of-concept  for  the 
EACE  technical  standard.  A  sensor- fusion  software  component  developed  for  the  Navy’s 
P-8  Poseidon  (a  maritime  patrol  aircraft  based  on  the  Boeing  737)  was  minimally 
modified  and  then  successfully  run  on  different  hardware  in  three  other  platforms:  a 
Boeing  AH-64  Apache  helicopter,  the  Sikorsky  S-99  Raider  technology  demonstrator, 
and  a  prototype  Boeing  computer  known  as  Phantom  Eusion  (Ereeburg,  2014). 
Honeywell  conducted  a  similar  study,  also  according  to  EACE  standards.  In  both  cases, 
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the  successful  result  points  optimistically  to  the  development  of  a  workable  open- 
standard  for  high-assurance  military  systems. 

By  themselves  however  two  successful,  independent  laboratory  tests  do  not  prove 
that  a  FACE-based  model  can  provide  adequate  real-world  performance  given  the 
limitations  of  currently  available  hardware.  “Any  time  you  introduce  an  open  system,” 
laments  Boeing’s  Dubois,  “you  are  introducing  extra  layers  of  processing”  (T.  Du  Bois, 
personal  communication,  September  25,  2014).  This  is  of  particular  concern  with  a 
highly-integrated  architecture  that  fuses  traditional  Mission  Systems  and  VMS  functions, 
where  performance  is  critical.  An  overburdened  capacity  for  real-time  processing  could 
set  limits  on  the  scope  of  virtualization,  especially  in  the  near-term,  without  the  added 
support  of  multi-core  processors. 

а.  TRL  Assessment  for  Open  Standard  Military  Avionics 

The  FACE  consortium  has  managed  to  build  apparent  momentum  behind  the 
adoption  of  an  accepted  open-standard  model  for  military  software  systems.  Given  the 
revolutionary  effect  that  successful  open-standards  in  telecommunications,  computer 
networking,  and  portable-device  operating  systems  have  had  over  the  past  few  decades, 
the  development  of  such  a  system  would  be  both  highly-welcome  and  long-overdue. 
Thus,  far  however,  the  FACE  standard  consists  of  little  more  than  some  documentation 
and  a  few  proof-of-concept  experiments.  Based  on  the  findings  of  our  research  we  will 
assign  it  a  current  TRL  rating  of  4;  “Component  and/or  breadboard  validation  in  a 
laboratory  environment”  ([ASD[R&E],  2011,  para.  2.5). 

б,  Model-Based  Systems  Engineering,  Development,  and  Certification 

The  complex  requirements  being  written  into  proposals  for  future  aircraft  (such  as 
EVE)  are  increasing  difficult  to  comprehend  intuitively.  Elaborate,  document-driven 
frameworks  such  as  DODAF  (Department  of  Defense  Architecture  Framework,  presently 
in  its  version  2.01  incarnation)  have  been  adopted  to  help  manage  this  growing  problem  - 
but  there  is  a  growing  sense  that  they  are  falling  short  of  the  task.  The  need  for  a  model- 
based  approach  was  a  consistent  thread  found  in  every  scholarly  article  and  conference 
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proceeding  on  IMA  eonsulted  for  this  study,  and  was  also  universally  endorsed  by  the 
subjeet-matter  experts  interviewed. 

In  a  June  2013  address  to  members  of  the  INCOSE  (International  Council  on 
Systems  Engineering),  Stephen  Welby,  Deputy  Assistant  Seeretary  of  Defense  for 
Systems  Engineering  expressed  his  view  that,  “we  will  begin  to  see  simulation  become  a 
more  integrated  part  of  the  design  process  rather  than  something  that  is  engaged 
separately.  I  believe  we  will  see  the  ability  to  affordably  explore  much  more  complex 
design  spaces,  with  the  opportunity  to  better  understand  how  the  implieation  of  design 
changes  downstream  ripples  back  across  an  entire  product  design”  (Zimmerman,  2014,  p. 
3). 

Proponents  of  model-based  systems  engineering  (MBSE)  claim  that  it  reduces  the 
chance  for  errors  and  ambiguities  to  develop  as  a  project  passes  through  the  many  stages 
required  to  translate  a  broadly-written  requirements  outline  into  aetual  working  software 
code.  Multiple  methodologies  of  MBSE  eurrently  exist,  and  are  defined  by  variances 
within  their  processes,  methods,  tools,  and  environment  (Estefan,  2008,  para.  2.1).  The 
approach  that  the  EACE  consortium  is  attempting  to  develop  for  use  on  the  JCA  and 
other  embedded  software-intensive  DOD  projects  is  called  the  Modular  Open  Systems 
(MOSA)  Data  Model.  It  has  been  demonstrated  in  principal  but  should  not  be  considered 
fully  mature.  In  a  November  2014  press-conference,  Michael  May,  the  associate  director 
for  software  and  embedded  systems  in  the  office  of  the  Assistant  Secretary  of  Defense  for 
Research  and  Engineering,  cited  the  pressing  need  to  reinvent  the  way  complex  aerospace 
and  weapon  systems  are  developed,  but  confessed  that  “Some  of  our  methods  don’t  scale 
well.”  (IE:  from  individual  software  programs  to  entire  systems).  They  also  rely  upon 
programming  and  formal  methods  of  analysis  that  are  still  not  the  norm  in  the  current 
work  force.  “The  formal-methods  guys  tend  to  be  PhDs,”  May  elarified  (Ereeburg,  2014). 
Eeft  unsaid,  but  presumably  a  limiting  factor  as  well  is  the  culture  and  environment  of  the 
DOD  aequisition  ecosystem.  It  remains  to  be  seen  if  the  good  intentions  of  the  EACE 
consortium  will  actually  succeed  in  bringing  about  any  meaningful  paradigm  shift  on  the 
equally  important  government  side  of  the  defense  technology  industry. 
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Testing  and  certification  are  also  areas  where  model-based  approaches  may  hold 
promise.  The  current  impasse  on  airworthiness  of  multi-core  processors  may  be  a  sign 
that  a  tipping  point  has  been  reached  in  our  ability  to  adequately  test  and  validate 
complex  cyber-physical  systems.  It  has  even  been  alleged  that  Boeing  purposefully  held 
back  on  integration  and  virtualization  in  the  787  airliner  because  they  feared  certification 
of  such  an  advanced  architecture  would  unduly  delay  sales  (D.  R.  Arterburn,  personal 
communication,  January  22,  2015).  In  order  to  continue  the  upward  trend  of  system 
complexity  and  capability,  the  pressure  is  on  to  reinvent  the  way  we  design,  test,  and 
certify  aircraft. 

Formal  recognition  of  MBSE  as  a  valid  approach  for  demonstrating  compliance 
with  applicable  airworthiness  regulations  may  finally  be  on  its  way;  2013  saw  the  FAA 
release  a  circular  (AC  20-1 15C  )  affirming  that  the  current  DO-178C  standard  could  be 
supported  via  model-based  testing.  Given  the  complexity  of  highly-integrated  future 
architectures—  especially  those  with  extensive  cognitive-decision  aiding,  or  optionally- 
manned  control  schemes  (as  planned  for  the  FVL)  -  there  is  still  a  long  way  to  go. 
Current  standards  are  still  based  on  deterministic  airworthiness;  implying  that  all  possible 
system  states  and  interactions  can  be  known  and  adequately  tested.  It  is  predicted  that  the 
F-35  will  reach  operational  service  with  some  24  million  lines  of  code  (Charrette,  2012); 
the  FVL  is  likely  to  be  just  as  complex.  Without  resorting  to  some  sort  of  probabilistic 
airworthiness  or  extensive  dependence  on  computer-based  simulation,  it  is  difficult  to 
fathom  how  we  will  be  able  to  certify  such  systems  in  a  time  and  cost-effective  manner. 

The  barriers  here  are  likely  more  cultural  than  technical.  “The  flight  test  guys 
sometimes  think  we’re  trying  to  put  them  out  of  business,”  explains  David  R.  Arterburn. 
(personal  communication,  January  22,  2015).  A  more  accurate  assessment  is  that  the  task 
of  flight  test  will  be  next-to-impossible  in  the  near  future  without  heavily  leveraging 
model-based  simulation,  but  live  testing  will  always  be  required  to  validate  parameters 
for  the  model.  With  assurance  that  the  input  is  valid,  developers  can  then  rely  upon  their 
model  environment  to  run  an  astronomical  set  of  scenarios  in  a  wholly  reasonable  time. 
Not  only  will  this  simplify  certification,  it  will  facilitate  the  early  discovery  (and 
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correction)  of  flaws  in  a  design  that  might  otherwise  be  accepted  because  they  were 
found  too  late  in  the  testing  process  to  economically  fix. 

It  is  important  to  emphasize  that  the  U.S.  government  and  defense  industry  is  not 
operating  in  a  vacuum  with  regard  to  the  modeling  and  simulation  issue.  SCARLETT 
researchers  at  the  University  of  Bremen,  Germany  in  2010,  published  detailed 
descriptions  of  model-based  testing  protocols  for  advanced  IMA  systems,  claiming  that 
“Compared  to  the  manual  implementation  of  tests  ...  this  approach  promises  to  reduce 
the  effort  needed  for  test  development  by  at  least  30%  and  to  avoid  errors  made  during 
the  manual  implementation  of  test  cases”  (Efkemann  &  Peleska,  2010,  para.  3).  EVE 
consultant  Arterbum  confirms  that  SCARLET  may  be  well-ahead  of  US-industry  in  this 
area.  “They  [European  Governments]  are  investing  heavily  in  this  stuff’  (D.  R. 
Arterburn,  personal  communication,  January  22,  2015). 

a.  TRL  Assessment  for  Model-Based  Development 

Our  findings  indicate  the  model-based  systems  development  is  a  rapidly 
advancing  field,  and  one  that — by  weight  of  necessity — is  likely  to  become  the  dominant 
paradigm  for  aerospace  systems  design  in  the  coming  decade.  As  evidenced  by  top-level 
comments  from  the  civilian  leadership  within  the  department  of  defense  (Zimmerman, 
2014;  Ereeberg  2014),  change  is  coming,  because  it  is  needed.  No  matter  what 
architecture  choice  is  arrived  at  for  the  EVE,  the  program  will  benefit  on  some  level;  but 
in  order  to  facilitate  development  of  an  advanced,  common  IMA2G  avionics  suite  for 
these  aircraft,  timely  adoption  is  of  pivotal  importance. 

Rating  the  TRL  for  model-based  development  strictly  in  the  context  of  EACE’s 
MOSA-data  model — the  system  most  likely  to  be  applied  to  the  EVE — we  find  level  7  is 
an  appropriate  reflection  of  the  current  status.  “System  Prototype  demonstration  in  an 
operational  environment.”  Though  not  strictly  speaking  a  part  of  the  technology  of  highly 
integrated  software-defined  systems,  the  relative  maturity  of  this  needed  faculty  lends 
some  needed  optimism  to  the  other  challenge  areas  described  previously. 
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B. 


IMA2G:  MATURITY  ASSESSMENT 


The  findings  of  Technology  Readiness  Assessment  are  summarized  in  Table  5. 


Table  5.  TRL  Summaiy  for  IMA2G  Critical  Path  Areas 


Technology 

TRL 

DOD  Definition 

Study  Findings 

Higli-speed 

networking 

6 

Systeni/'subsystem  model  or 
prototype  demonstration  in 
a  relevant  enviromnent. 

TTEtlieinet  has  demonstrated  characteristics 
needed  to  support  IMAZGf  11.121 

Has  not  been  integrated  beyond  prototype 
applications  in  an  air  vehicle. 

The  Automobile  industry  is  investing  in  this 
technologyfdl. 

Deterministic  MCP 

4 

Component  anchor 
breadboard  validation  in  a 
laboratory  ensiromnent. 

No  current  MCPs  are  certified  airwortliy  [41 

Disabled  MCPs  are  flying  without  clear 
airworthiness  f51 

Vender  Wind  River  Systems  recently  promised  a 
compliant  RTOS  that  can  leverage  dual-core 
silicon,  but  has  not  yet  deliveredlbl. 

Single-core  processors  may  be  obsolete  in  5 
yeaisf4l.f71 

High-Assm-ance 

Virhialization 

3 

Analytical  and  experimental 
critical  function  and  or 
proof  of  concept 

Paravirtualization  is  a  mature  technology,  but 
may  not  be  suitable  to  military  IMA2  0181. 191 

Hardw’are-assisted.  fuU-virtualization  is  tied  with 
chip-design,  and  such  products  are  not  yet 
available  to  assess. 

High-Robustness 

Virtualization 

4 

Component  and  or 
breadboard  validation  in  a 
laboratory  ensiromnent. 

Integrity  DO-178  RTOS  offers  a  MILS  compliant 
secure  VMM.  already  certified  and  in  use  aboard 
operational  military  aircraft  191 

Current  Integrity  applications  do  not  stress  the 
system  to  the  extent  that  an  IMA2G  architecture 
might. 

Open  Standards 
Integration 

4 

Component  andor 
breadboard  validation  in  a 
laboratory  ensiromnent. 

FACE  consortimn  technical  standard  continues  to 
evolve  and  has  broad  industry  supportf71.1 101 

Independent  JCA  experiments  have  demonstrated 
that  the  proposed  open  architectme  is  feasible. 

[11] 

Model-based, 
design,  test  & 
ceitification 

7 

System  Prototype 
demonstration  in  an 
operational  emiromnent 

Multiple  demonstrations  of  need/capability  intent 
fi'om  both  industry  and  govemment.l  1 111121 

Cultural  fiictors  may  retard  full  adoption  1711101 

1.  Kopetz,  Ademaj.  &  Ghllinger.  2005  7.  D.R.  Arterbum,  personal  communication,  January  22,  2015 

2- Bisson,  2011  8.  Fuchsen,  2009 

3.  Plankensteiner,  2012  9.  Kleidenuacher  &  Wolf,  2008 

4.  Huyck.  2012  10.  T.  Du  Bois,  personal  communication,  September  25,  2014 

5.  Reported  in  confidential  personal  communication  11.  Freeburg,  2014 

6.  Wlad.  2014  12,  Zimmerman.  2014 
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Overall  it  may  seem  that  the  low  ratings  (averaging  only  4.7  on  a  scale  of  1-9) 
pamt  of  bleak  pictme  for  the  shoit-teiin  prospects  of  second-generation  IMA.  It  should  be 
kept  in  mind  however  that  the  technology  areas  listed  in  this  portion  of  the  study 
represent  critical  path  items  in  the  development  of  such  a  system.  It  is  not  inclusive  of 
the  many  matme  or  nearly-matme  teclmologies  that  would  also  be  leveraged  m  a  notional 
IMA2G  design.  Had  we  listed  oin  identified  challenge-areas  alongside  all  these  other 
low-risk  items,  the  outlook  nahually  appear  much  more  optimistic.  Since  a 
developmental  system  can  easily  be  derailed  by  its  weakest  luik  however,  we  feel  the 
pictiue  as  described  in  the  following  table  is  the  better  one  from  which  to  fonnulate  a 
recommendation. 

C.  IMA2G  IMPACT  ON  FVL  ATTRIBUTES 

As  outlmed  in  chapter  n  of  this  study,  the  Fufrue  Veifical  Lift  progiam  ICD  sets 
out  a  broad  set  of  highly  ambitious  requuemeuts.  In  this  section,  we  will  assess  the 
potential  impact  of  a  fully-realized  IMA2G  architecfrue  on  individual  aspects  of  those 
requirements,  as  well  as  the  relative  potential  for  a  less-integiated  system  to  acliieve  those 
same  thresholds. 

1.  Aircraft  Performance/Payload/Range 

Table  6  lays  out  a  stark  comparison  between  the  perfomiance  threshold  expected  of  the 
medium-weight  FVL  var  iant  and  one  of  the  more  avionics-weight-challenged  challenged 
aiicraft  it  would  one  day  ftilfrll  the  role  of,  the  U.S.  Navy’s  Sikorsky  SH-60B. 


Table  6.  FVL-medimn  and  SH-60B  perfonnance  compared 


Speed  (cruise) 

Combat  Radius 

Payload  (int/ext) 

Passengers 

SH-60B 

120  (max  range) 

80  nm* 

600-3000  lbs 

1-2 

FVL-M 

230-300  kts 

265  nm* 

6,000-20,000  lbs 

11-24 

*  Defined  as  umefireled  distance  w/2.0  hr'  loiter  (full  combat  load  at  6k/95°) 
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Though  the  size,  weigh,  and  power-consumption  (SWAP)  benefits  of  a  more 
efficient,  integrated  avionics  package  are  not  enough  to  deliver  the  required 
improvements  on  their  own,  they  could  make  a  significant  contribution  -  both  on  their 
own,  and  synergistically. 

•  Reduced  Avionics  Size;  increases  the  volume  of  internal  fuel  that  can  be 
carried,  increasing  range,  and  on-station  endurance.  If  those  benefits  are 
sufficient  to  eliminate  the  need  for  external  fuel  for  certain  missions,  the 
increased  speed  may  be  realized  through  reduction  in  drag,  or  increased 
armament/payload  can  be  carried. 

•  Reduced  Avionics  Weight:  Improves  rate  or  climb,  top-speed,  and  range. 
In  Helicopters,  contributes  to  better  hover  performance  and  controllability 
under  hot/heavy/high  conditions.  Also,  more  fuel  can  be  carried,  (internal 
or  external)  increasing  range.  Payload  (external/intemal)  and  armament 
also  can  be  increased. 

•  Reduced  Power  Consumption;  Reduces  size/weight  of  generators/power- 
supply  busses,  wiring,  and  cooling  systems  required,  contributing  to 
range/speed/payload/armament  improvements.  Reduction  in  parasitic  drag 
on  engines  to  run  generators  may  also  contribute  slightly  to  performance. 
Alternately,  these  small  benefits  could  be  traded  in  for  greatly  increased 
excess  power-capacity  for  high-draw  weapons  and  sensors. 

•  Synergistically:  reduction  in  all  three  aspects  of  size,  weight  and  power  in 
on-board  avionics  have  a  ripple-effect  across  the  entire  airframe,  allowing 
for  more  efficient  packaging,  and  reduced  design-penalties  for  the 
delivered  capabilities. 

The  ability  for  first-generation  IMA  to  deliver  size,  weight  and  power  savings 
has  already  been  discussed  in  this  work.  The  2014  report  by  Mairaj  and  Tahir 
demonstrate  that  size  reductions  on  the  order  of  28%  to  50%,  weight  reductions  of  25% 
to  50%,  and  power-consumption  reductions  of  38%  to  60%  are  possible  when 
transitioning  to  from  a  federated-systems  model  to  an  IMA-based  model.  There  is 
abundant  cause  to  speculate  that  a  second-generation  IMA  avionics  suite  would  improve 
significantly  on  those  already-impressive  figures.  However,  since  there  is  no  flying 
example  of  true  IMA2G  architecture  at  this  time,  no  equivalent  data  exists  to  validate  that 
hypothesis,  much  less  quantify  it  statistically.  For  the  purposes  of  this  study  we  will 
adhere  to  a  conservative  estimation,  assuming  that  the  adoption  of  fully-developed 
IMA2G  avionics  and  mission-systems  will  realize  SWAP  improvements  in  the  FVL  no 
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greater  than  the  upper-bounds  already  reported  in  the  Mairaj  and  Tahir  paper:  50%  size, 
50%  weight,  and  60%  power  consumption. 

Just  how  mueh  of  a  real-world  performance  improvement  would  those  figures 
translate  to  for  an  FVL  rotorcraft?  As  discussed  previously,  that  will  depend  largely  upon 
the  ratio  of  avionics  weight  to  aircraft  empty  weight.  In  an  attempt  to  estimate  what  that 
ratio  might  be  for  an  FVL-medium  variant  (which  will  probably  be  the  most  numerous 
derivative),  we  have  compiled  data  from  a  1981  Rand  Corporation  study  that  included  a 
breakdown  of  avionics  weight  for  various  then-current  U.S.  combat  aircraft.  Added  to  the 
list  is  corresponding  empty  weight  and  avionics  weight  for  the  SH-60B  Seahawk 
helicopter,  which  was  introduced  to  service  around  the  same  time  as  the  Rand  study  was 
conducted.  Columns  B  through  D  in  Table  7  represent  the  as-is  state  for  complex, 
federated-systems  military  aircraft  of  varying  sizes.  Note  that  the  percentage  of  total 
empty  weight  represented  by  on-board  avionics  is  highest  in  the  SH-60B,  at  14.6%.  With 
a  50%  reduction  in  weight  accomplished  through  advanced  IMA  (remember,  a 
conservative  figure)  that  percentage  would  decline  to  7.9%  (Column  F),  reducing  the 
overall  aircraft  empty-weight  by  a  very  significant  7.3%. 

If  100%  of  the  weight  shed  (nearly  a  thousand  pounds)  were  to  be  translated 
directly  into  a  corresponding  quantity  of  extra  onboard  fuel,  the  increase  in  range  would 
significant.  According  to  type-model  NATOPS  manual,  the  SH-60B  normally  carries 
approximately  3000  lbs  of  fuel;  enough  to  support  3.5  hours  of  total  endurance,  or  a  80 
mile  transit,  with  a  2  hour  on-station  time,  and  80  mile  return.  Adding  996  lbs  of  internal 
fuel  would  allow  for  a  140  mile  two-way  transit  with  the  same  2  hour  on-station  time.  In 
other  words,  notwithstanding  any  aerodynamic  gains  made  though  the  FVL’s  proposed 
compound-helicopter  or  tilt-rotor  layout,  just  building  the  aircraft  around  a  IMA  mission- 
systems  suite  could  improve  combat  radius  by  75% ! 
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Table  7.  Avionics  as  percent  of  empty  weight:  Federated  vs.  IMA 


B 

C 

D 

E 

F 

G 

H 

As-is 

IMA2G  (  with  50%  weight-reduction  in 
avionics) 

Empty 

Weight 

Avionics 

Weight 

%of 

empty 

weight 

Avionics 

Weight 

%of 

empty 

weight 

Empty 

Weight 

Weight 

reduction% 

F-14A  [1] 

38,900 

2,199 

5.7% 

1,099 

2.9% 

37,801 

2.8% 

F-15A  [1] 

25,800 

1,580 

6.1% 

790 

3.2% 

25,010 

3.1% 

F-lllD  [1] 

46,800 

2,354 

5.0% 

1,177 

2.6% 

45,623 

2.5% 

A-4M  [1] 

10,800 

840 

7.8% 

420 

4.0% 

10,380 

3.9% 

SH-60B 

[2][3] 

13648* 

1,997* 

14.6% 

996 

7.9% 

12,652 

7.3% 

1  Dryden,  Britt,  &  Blnnings-Deprlester,  1981,  p.  29 

2  Polmar,  2001,  p.  389 

3  NAVAIR,  SH-60B  NATOPS  manual 

*  Does  not  include  weight  of  FLIR/HdIfire  package  (add  700+lbs) 


If  the  FVL  ahfiame  Umis  out  to  be  capable  of  delivering  the  requhed 
range  improvements  without  cairying  extra  onboard  firel,  that  weight  and  space  saving 
could  be  traded  toward  other  performance  enhancements,  irrchrding  speed, 
maneirverability,  hot/heavy/high  hover  ability,  and  cargo/weapons  payload. 

a.  Impact  Assessment  for  Performance/Range/Payload 

Given  the  high  percentage  of  aucraft  empty  weight  likely  to  be  devoted  to 
avionics  in  a  complex  mirlti-mission  platform  like  the  FVL-rnedirrm,  the  projected 
SWAP  gains  of  IMA2G  (rrpwards  of  50%  for  size,  50%  for  weight,  and  60%  for  power- 
consirmption)  are  likely  to  be  highly  significant  to  aucraft  performance.  Likewise,  the 
consequence  of  attempting  to  achieve  the  desued  mrrlti-mission  capability  without 
resorting  to  a  highly-integrated  avionics  architectiue  is  likely  to  be  highly  detrimental.  In 
other  words,  conmirmications,  sensors  or  weapons,  woirld  have  to  be  traded  for  speed  and 
range,  or  vice  versa.  With  firlly-realized  IMA2G,  the  trade-off  wortld  be  greatly  redirced. 
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In  accordance  with  this  study’s  findings,  we  rate  the  impact  of  advanced  IMA  on 
achieving  the  desired  performance  characteristics  of  the  FVL  program  as  strongly 
positive. 

2.  Mission  Capability/Flexibility 

FVL  program  attributes  and  outcomes  associated  with  Joint  Forces  (JFOR) 
Mission  Capability/  Flexibility  include  the  following: 

•  The  ability  to  integrate  and  rapidly  configure  a  mixture  of  “multiple  Joint 
weapon  types” 

•  Advanced  Sensors  that  combine  “multi-spectral,  multi-function  ... 
targeting,  navigation,  and  aircraft  survivability  equipment”  and  the  ability 
to  operate  at  night  and  in  degraded  visibility. 

•  Enhance  Situational  Awareness  through  various  data-links  that 
automatically  send/receive  information  and  help  build  a  common 
operating  picture,  including  “threats,  inclement  weather,  and  other  hazards 
encountered  enroute.” 

•  Fully  integrated  crew  station  to  enable  “mission  focused  operation”  while 
providing  for  “automation  of  critieal  battle  tasks,  eognitive  decision 
aiding,  and  decision  making,  [and]  fused  sensor  imagery.” 

(US  Department  of  the  Army  [USA],  2011,  p.  3) 

The  total  picture  that  emerges  when  looking  at  the  above  requirements  is  of  an 
extremely  complex  aircraft  with  numerous  sensors,  communication  systems,  weapon 
systems,  and  a  centralized  management  capacity  for  the  interpretation  and  presentation  of 
information.  What  would  happen  if  an  attempt  was  made  to  integrate  such  advanced 
eapabilities  into  an  existing  airframe  without  resorting  to  an  advanced  IMA  architeeture  ? 
(Assuming  it  is  even  possible  to  design  a  system  like  this  under  the  federated  model.)  As 
it  turns  out,  we  have  a  perfect  experimental  case  to  answer  that  very  question:  the  MH- 
60R  -  which  is  now  replacing  the  SH-60B  in  service  with  the  U.S.  Navy.  While  the 
“Romeo”  certainly  succeeds  in  upgrading  the  weapon  suite,  sensor  reach,  data-link 
capability,  and  cockpit  presentation  of  the  legacy  platform  is  has  supplanted,  the 
corresponding  increase  in  empty  weight  is  illustrative. 
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Table  8.  Avionics  complexity  and  aiicraft  weight;  SH-60B  to  MH-60R 


SH-60B 

MH-60R 

Empty  Weight 

13,648*  fl] 

15,200  [2] 

Gross  T/O  weight 

21.700  lbs  [11 

23,500  lbs  [21 

r  NAVAIRSH-60BNATOPS  manual 

2  NAVAIR  MH-60R  NATOPS  manual 

*  Does  not  include  weight  of  FLIR/Hellfire  package  (add  700+lbs) 

Essentially,  the  MH-60R  features  the  same  auframe  as  the  SH-60B.  hideed  the 
first  TRIP  (Low-Rate  Initial  Production)  batch  of  “Romeos”  were  built  fioni  existmg 
60B,  60F  and  60H  auframes.  The  weight  growth  shown  in  Table  8,  is  almost  all 
attributable  to  either  1.)  avionics  systems  growth,  or  2.)  aufiame  reinforcement  and 
auxiliary  support  systems  designed  to  accommodate  that  avionics  growth. 

As  capable  as  the  MH-60R  is  with  regard  to  mrrlti-mission  flexibility,  weapon 
employment,  and  serrsor-firsion,  it  represents  only  the  current  state-of-the-art,  arrd  falls 
well-short  of  the  corresponding  characteristics  described  in  the  FVL  ICD.  By  2035,  the 
FVL’s  intended  IOC,  the  “Romeo”  will  be  as  moribrmd  and  obsolete  as  the  SH-60B  is 
today.  To  add  the  capabilities  called  for  in  the  FVLFOS  ICD  without  an  advanced  IMA 
architectrrre  woirld  add  even  more  weight  to  an  aucraft  that  is  aheady  reaching  the  irpper 
boimds  of  what  the  au  fi  ame  and  powerplarrts  can  support. 

That  argimrent  may  be  academic  however,  as  the  type  of  airtomation,  information¬ 
sharing,  and  in-flight  reconfigiuation  called  for  in  FVL  docirments  may  be  all  brrt  im- 
achievable  without  a  software-defined  approach  to  system  integration. 

a.  Impact  Assessment  for  Mission  Capability/Flexibility 

Not  siuprismgly,  oru  firrdings  mdicate  that  sirccessfirl  development  of  an 
advanced  IMA2G  architectrue  for  the  FVL  Family  of  Systems  woirld  have  a  strongly 
positive  impact  on  achieving  program  thresholds  for  mission  capability  and  flexibility. 
Any  attempt  to  achieve  greater  sensor-ftrsion,  weapon  mtegration,  or  battle-space 
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awareness  over  the  current  MH-60R  multi-mission  maritime  helicopter  would  likely 
result  in  severe  SWAP  consequences. 


3,  Manpower/Training 

The  optimal  manning  required  to  maintain  a  military  aircraft  at  the  desired  level 
of  operational  availability  varies  with  the  characteristics  of  the  aircraft  in  question. 
Airframe  size  and  complexity  play  a  key  role,  but  the  electronic  and  avionics  architecture 
is  also  highly  influential,  particularly  when  FMC  (Full-Mission-Capable)  rates  are 
considered.  Although  the  concept  of  the  LRU  was  supposed  to  simplify  field 
maintenance,  in  reality,  a  complex  federated  architecture  requires  a  large  footprint  of 
maintenance  manpower. 

•  Large  number  of  individual  physical  components  and  connections  between 
them  create  numerous  potential  points  of  failure. 

•  Software  and  hardware  are  tightly  coupled,  making  it  difficult  to  isolate 
whether  a  fault  is  in  one  or  the  other. 

•  Built-In-Testing  (BIT)  on  LRUs  does  not  span  system  wide,  resulting  in 
ambiguous  results  and  unnecessary  replacement  is  order  to  chase  faults. 

•  Depot-level  maintenance  requires  numerous  specialists  to  effect  repairs  on 
unique  LRU  components. 

•  Lack  of  commonality  between  federated  platforms  favors  specialization 
over  generalization,  resulting  in  a  larger  maintenance  manning  footprint. 

The  first  commercial  developments  of  IMA  meanwhile  were  sold  as  much  on  the 
basis  of  reducing  that  heavy  maintenance  footprint  as  they  were  on  SWAP 
considerations.  IMA  in  general,  and  advanced  IMA  in  particular,  directly  addresses  all 
the  previously  described  causal  factors  that  inflate  the  maintenance-manning 
requirements  of  a  federated-systems  fleet.  The  mechanisms  for  that  enhanced  efficiency 
are  as  follows: 


•  Reduced  number  of  unique  hardware  components  and  fewer  connections 
and  junctions  in-between,  resulting  in  limited  physical  points  of  failure. 

•  Software  and  hardware  faults  are  inherently  easier  to  separate  in  an  IMA 
scheme. 
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•  Advanced,  autonomous,  system-wide  conditional-monitoring  can  isolate 
and  announce  faults  before  they  even  beeome  apparent  to  operators. 

•  Fewer  physieal  components  in  the  avionies  system  means  fewer  specialists 
required  at  the  depot-level. 

•  System  eommonality  across  platforms  allows  a  single  qualified  maintainer 
to  work  on  multiple  airframes  with  equal  competence. 

This  last  characteristic  is  particularly  germane  to  the  FVL  program.  A  forward- 
deployed  force  pays  a  logistieal  premium  for  maintenanee  manpower;  and  vertical  lift 
aircraft  are  often  deployed  to  austere  loeations  where  seeurity,  supplies,  and  even  shelter 
are  limited.  When  two  avionies  teehnicians  at  a  small  FOB  (Forward  Operating  Base)  ean 
do  the  job  of  three  or  four,  or  when  one  teehnieian  ean  work  on  multiple  FVL  types,  the 
benefits  are  particularly  manifest.  In  operational  terms,  a  manpower  reduetion  of  this 
order  -  with  no  eorresponding  downgrade  to  capability  -  means  that  the  FOB  has  a 
lighter  logistical  footprint  to  support  and  can  thus  hold  out  longer  between  resupply 
missions. 

Advaneed  IMA  arehitectures  would  also  be  likely  to  use  more  commereial,  open- 
source  software  to  deliver  eommon,  non-tactical  functionality  -  as  opposed  to  proprietary 
military  programs.  Greater  convergence  between  skill  sets  utilized  in  the  military  and 
civilian  spheres  broadens  the  pool  of  experienced  technieians,  and  can  be  leveraged  to 
motivate  both  reeruitment  and  (to  an  extent)  retention  of  military  technieians.  This  may 
be  mitigated  perhaps  by  the  higher  level  of  knowledge  and  edueation  required,  but  in  the 
long  term,  sueh  an  effect  would  be  in-line  with  the  apparent  U.S.  soeietal  trend  toward 
inereased  educational  requirements  for  employment.  Without  doubt,  young  people 
entering  the  work  foree  today  are  more  eomfortable  and  conversant  with  software-driven 
systems  than  any  previous  generation — to  say  nothing  of  those  entering  the  work  force  in 
2035!  (Of  course  it  remains  to  be  seen  however  whether  that  high-level  familiarity 
aetually  translates  into  functional  understanding.) 

Operator  training  and  manning  meanwhile,  may  also  benefit  from  adoption  of  a 
common  IMA  architecture  across  the  FVL  Family  of  Systems.  Shared  eoekpit  interfaces 
enable  easier  cross-platform  type  rating.  Optionally-manned  capabilities  (whieh  would  be 
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far  easier  to  implement  in  an  IMA2G  arehiteeture)  eould  reduee  the  number  of  human 
pilots  and  airerewmen  required  -  at  the  very  least  be  taking  on  routine  maintenanee  or 
ferry  flights.  The  ability  to  operate  instanees  of  mission  software  fully  abstracted  from 
hardware  and  linked  by  a  common  virtual  environment  opens  the  possibility  of  using  an 
FVL  aircraft  as  a  full-function  tactical  simulator  for  deployed  forces.  A  crew  could 
practice  for  an  upcoming  mission,  participate  in  a  battle-group  war-game,  or  even  catch 
up  on  their  yearly  instrument  approach  minimums  without  ever  leaving  the  ground. 
Limited  aircraft  maintenance  (daily  and  turn-around  servicing  for  instance)  could  even  be 
conducted  at  the  same  time  on  a  non-interfering  basis.  Later,  after  the  mission  was 
actually  flown,  data  collected  and  fused  from  the  on-board  network  of  embedded  systems 
could  be  used  to  re-construct  events,  aircraft  performance  and  crew  actions  in  rich  detail. 

a.  Impact  Assessment  for  Manpower/T raining 

As  a  result  of  the  reduced  physical  complexity,  but  increased  logical  complexity 
of  IMA  systems,  fewer  maintenance  personnel  will  be  needed,  but  for  those  that  are 
retained,  a  higher  (more  software-focused)  level  of  expertise  will  be  called  for.  This  may 
have  both  positive  and  negative  repercussions  for  military  technician  recruitment  and 
competition  against  private-sector  employers,  but  overall,  the  balance  is  likely  to  be  in 
favor  of  IMA. 

On  the  operational  training  aspect,  advanced  integrated  systems  offer  many 
possibilities  to  make  more  effective  use  of  pilot/aircrew  time  and  enhance 
training/readiness.  As  a  result,  we  assess  that  IMA2G  is  likely  to  have  an  overall  positive 
effect  on  manpower  considerations  for  the  FVL  program. 

4.  Development  Timeline 

Application  of  any  novel  technology  (or  in  the  case  of  IMA2G,  several  novel 
technologies)  carries  inherent  schedule  risk.  Earlier  in  this  chapter,  we  assessed  the 
overall  Technology  Readiness  Level  for  advanced  IMA  architectures  as  approximately 
4.7  on  a  scale  of  1-9.  This  limited  state  of  maturity  of  increased  the  probability  of 
unknown-unknowns  emerging  during  the  course  of  system  development. 
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Given  novel  airframe  arehitecture(s)  proposed  for  the  FVLFOS  however,  it 
cannot  be  taken  for  granted  that  delays  with  avionics  will  be  the  critical  path  that  causes 
overall  schedule  slippage.  An  instructive  parallel  might  be  Boeing’s  development  of  the 
787  Dreamliner.  Company  executives  launched  the  program  in  January  of  2003,  with 
intent  for  first  deliveries  by  the  end  of  2008  -  assuming  it  would  take  just  six  years  to 
design,  build,  test  and  certify  the  new  machine.  This  aircraft’s  fully-fledged  First- 
Generation  IMA  architecture  represented  a  very  large  advance  over  the  previous 
transitional  IMA  applied  to  the  company’s  777  airliner;  but  the  aircraft  also  employed 
extensive  use  of  composite  construction  that  was  without  precedent  for  an  aircraft  of  its 
class.  The  confluence  of  these  two  factors  make  it  difficult  to  sort  out  which  one 
(avionics  or  airframe)  was  predominantly  responsible  for  the  three-year  schedule  slip  in 
actual  customer  deliveries. 

IOC  for  the  FVL-Medium  variant  (the  first  to  be  fielded)  is  2035.  Given  that  Joint 
Multi  Role  Technology  Demonstrator  (JRM-TD)  prototypes  should  have  completed  their 
fly-off  competition  by  the  end  of  2018,  the  projected  timeline  allows  for  twelve  years  of 
further  development.  Compared  to  almost  any  other  similar  program  (with  the  possible 
exception  of  the  notoriously  tardy  V-22  Osprey)  this  seems  like  a  generous  schedule. 

Moreover,  the  extremely  high-level  of  complexity  inherent  to  an  advanced 
IMA2G  architecture  in  a  multi-mission  tactical  aircraft  makes  model-based  design  and 
testing  a  virtually  inescapable  necessity.  All  subject  matter  experts  contacted  for  this 
study  agree  firmly  on  that  point.  This  forced  transition  is  likely  to  make  progress  more 
difficult  at  first,  but  if  advocates  of  MBSE  are  right,  it  will  pay  significant  dividends  in 
the  long-term,  greatly  streamlining  the  development  process.  Given  the  long-term  scope 
of  the  FVL,  the  program  is  likely  to  benefit  from  that  effect  eventually  -  perhaps  even 
enough  to  make  up  for  initial  delays. 

Another  factor  to  be  considered  is  the  ease  with  which  open-source,  COTS,  or 
legacy  software  components  could  be  integrated  into  an  advanced  IMA2G  system.  This 
characteristic  is  one  of  the  most  heralded  advantages  of  IMA2G,  and  has  the  potential  to 
radically  streamline  avionics  capability  development.  As  noted  previously  in  this  chapter, 

experiments  with  the  FACE  consortium’s  technical  standard  for  Modular  Open  Systems 
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Architecture  (MOSA),  have  already  demonstrated  the  feasibility  of  cross-platform 
software  re-use. 

a.  Impact  Assessment  for  Development  Timeline 

On  the  whole,  it  is  difficult  to  predict  the  impact  of  IMA2G  architecture  on  the 
FVL  program.  Due  to  the  novel  (and  as-yet  undetermined)  airframe  construction,  the 
immature,  but  rapidly-developing  state  of  required  technology,  and  an  on-going  paradigm 
shift  within  Government  and  Industry,  any  projection  would  be  highly  speculative.  The 
relative  speed  and  success  of  the  transition  to  model-based  development,  and  MOSA  will 
strongly  impact  the  schedule  of  the  FVL  program;  but  investing  in  a  heavily-integrated 
IMA  architecture  is  more  likely  to  force  these  issues. 

Since  equal  potential  exists  for  IMA2G  adoption  to  delay  or  enhance  the  FVL’s 
acquisitions  schedule,  we  assess  the  impact  as  neutral/indeterminate  for  the  purposes  of 
this  study. 


5.  Total  Life-Cycle  Costs 

Many  of  the  same  characteristics  of  IMA  that  would  positively  impact 
maintenance  manning  would  be  reflected  in  reduced  life-cycle  expenditures.  It  stands  to 
reason  that  a  system  with  fewer  physical  parts,  fewer  redundant,  duplicated  capacities, 
and  greatly  reduced  wire  count  would  also  be  less  expensive  to  maintain  and  repair.  Each 
LRU  in  a  federated-systems  model  (and  a  single  function  require  many  LRUs)  represents 
an  tightly-coupled  integration  of  hardware  and  software,  and  testing  program  to  validated 
it.  It  is  not  unreasonable  to  expect  that  a  system  with  90%  fewer  LRU’s  would  be 
significantly  reduce  maintenance  and  upgrade  costs. 

Achieving  enhanced  efficiency  in  software  development  and  integration  is  of 
course,  one  of  the  major  factors  driving  IMA  and  advanced  second-generation  IMA. 
Avionics  contractor  Honeywell,  for  instance,  claims  to  have  reduced  software  costs  20% 
for  the  avionics  suite  onboard  the  Boeing  777  ER  (http://www5Lhoneywell.com/).  In 
particular,  the  high  degree  of  software  re-use  possible  with  a  heavily  virtualized  avionics 
computing  environment  would  seem  to  open  the  gate  to  very  impressive  savings.  In 
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general,  it  eosts  the  same  to  develop  a  partieular  software  paekage  irrespeetive  of  how 
many  aireraft  that  software  ends  up  installed  in.  Clearly,  if  a  single  software  eapability 
ean  be  re-used  aeross  multiple  different  aireraft,  entire  development  programs  ean  be 
redueed  to  mere  integration  efforts.  That  integration  itself  beeomes  immensely  easier  the 
more  abstraeted  the  software  runtime  environment  is  from  the  underlying  hardware. 
Much  of  integration  testing,  after  all,  involves  the  quest  to  discover  and  eliminate  adverse 
interactions  between  component  and  another  (hardware  or  software).  The  isolation  of  a 
“guest”  operating  system  within  a  virtual  environment  can  help  contain  those 
interactions. 

Furthermore,  an  FVL  aircraft  equipped  with  IMA2G  avionics  might  well  be  able 
to  integrate  obsolete  legacy  programs  supporting  sensors,  communications  or  weapon 
systems  introduced  decades  earlier;  just  as  one  might  run  an  obsolete  version  of  Windows 
in  a  virtual  machine  on  one’s  personal  computer  to  allow  a  superseded  application  to  run. 
This  could  take  what  might  have  otherwise  been  a  long  and  costly  integration  program 
and  greatly  reduce  the  time  and  expense. 

Of  course,  public  funds  expended  in  developing  software  for  military  aircraft  are 
merely  the  tip  of  the  proverbial  iceberg.  According  to  a  recent  U.S.  Air  Force  study, 
“software  sustainment  activities  (i.e.,  O&M  plus  upgrades)  can  account  for  60-90%  of 
the  total  life  cycle  software  costs”(USAF  Science  and  Advisory  Board  [SAB],  2011,  p. 
75)  and  those  costs  are  trending  strongly  upwards.  The  same  report  found  that 
expenditures  on  software  maintenance  “nearly  doubled  over  the  past  decade  (an  increase 
from  $483M  in  2002  to  $841M  in  2011)”  (SAB,  2011,  p.  74).  and  predicted  they  would 
continue  to  climb  over  the  next  two  decades  as  highly  software-dependent  aircraft  like 
the  F-22  and  F-35  enter  the  sustainment  phases  of  their  life-cycle. 

Again,  there  is  little  difference  in  the  costs  to  maintain  a  particular  software 
configuration  item  whether  it  is  used  in  one  aircraft  or  many.  Any  reduction  in  the 
number  of  unique  software  programs  used  across  the  FVL  fleet  would  help  contain 
sustainment  costs.  If  extensive  virtualization  means  that  software  and  hardware  can  be 
upgraded  separately  and  independently,  the  ease  of  upgrading  FVL  variants  during  their 

life-cycle  would  also  be  enhanced.  It  might  also  lead  to  more  competitive  market 
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conditions  among  vendors  and  bring  down  prices.  Contrast  this  to  the  current 
circumstance  where  the  DOD  typically  finds  itself  held  hostage  to  a  single  supplier  of  an 
obsolete  processor  or  software  item.  Often  times,  the  vendor  may  be  forced  by  economic 
factors  to  discontinue  the  product,  leaving  that  particular  military  system  vulnerable  to 
widespread  service  outage. 

a.  Impact  Assessment  for  Total  Life-Cycle  Costs 

Few  matters  in  business  or  government  are  as  contentious  and  often-exaggerated 
as  the  potential  for  long-term  cost  savings.  Despite  the  preponderance  of  claims  that 
advanced  IMA  architectures  will  be  less  expensive  to  upgrade  and  maintain  over  the  life 
of  an  aircraft,  there  is  little  present  evidence  in  the  public  domain  to  quantify  that.  Recall 
that  even  the  initial  generations  of  IMA  architected  aircraft  have  not  yet  reached  the  back 
half  of  their  service  lives,  where  maintenance  and  upgrade  costs  are  likely  to  be  highest. 
Furthermore,  most  of  these  planes  are  operated  by  profit-driven,  publicly-traded 
corporations,  who  are  understandable  tight-lipped  about  the  actual  monetary  figures 
involved.  Thus,  all  we  are  left  with  is  expansive  sales  pitches  from  manufacturers  -  who 
can  hardly  be  expected  to  present  a  sober  and  restrained  sales-pitch.  Even  if  the  massive 
cost-efficiencies  promised  by  IMA  vendors  and  advocates  turn  out  to  be  achievable,  the 
initial  cost  of  entry  into  state-of-the-art  technology  cannot  and  should  not  be  ignored. 

That  being  said,  our  findings  indicate  little  reason  for  outright  pessimism.  Viewed 
strictly  in  the  long  term,  we  find  there  is  reason  to  expect  that  IMA2G  would  indeed  carry 
a  positive  impact  on  life-cycle  costs  for  the  FVLFOS.  This  might  be  partially  mitigated  in 
the  short  and  medium-term  however  by  larger  up-front  costs,  but  the  FVL  program  as  a 
whole  is  large  enough  to  support  such  costs,  and  long  enough  in  scope  to  reap  the 
rewards. 


6,  Enhanced  Safety  and  Survivability 

In  the  first  six  years  of  combat  operations  in  Iraq  and  Afghanistan,  375  rotary 

wing  aircraft  were  lost  as  a  result  of  enemy  fire,  aircrew  mishap,  or  mechanical  failure 

(Couch  &  Lindell,  2010,  p.  9).  To  what  extent  could  adoption  of  software-defined 

avionics  help  enhance  the  flight  safety  and  combat  survivability  of  Future  Vertical  Lift 
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aircraft?  As  it  turns  out,  there  are  multiple  aspects  where  IMA2G  could  have  a  positive 
impaet: 

•  More  armor /protection.  As  previously  shown  IMA2G  would  save 
considerable  weight.  Every  pound  of  avionics  and  wiring  saved  could  be 
replaced  with  a  pound  of  additional  armor  and  countermeasures. 

•  Greater  performance  margin.  Alternately,  weight  savings  from  IMA2G 
could  mean  a  lighter,  faster,  more  maneuverable  FVL,  better  able  to  evade 
enemy  fire,  and  more  resilient  to  the  hazards  of  mountain-flying. 

•  Enhanced  resiliency.  An  IMA2G  architecture  eould  distribute  critieal 
avionics  functionality  across  several  deeentralized  servers,  running 
parallel  software  instances.  Battle  damage  or  power  failure  to  one  server 
rack  would  result  in  seamless  “failover”  -  or  transfer  of  proeessing 
responsibility  to  the  alternate  server. 

•  Enhanced  awareness.  IMA2G  supports  the  integration  of  numerous, 
advanced  sensors  (at  redueed  SWAP  penalty)  to  detect  threats,  and  present 
them  to  the  pilots  and  airerew  in  an  intuitive,  helpful  manner. 

•  Cognitive  decision  aiding/ Assisted  piloting.  Centralized  fusion  of  data  in 
IMA  allows  for  the  possibility  of  effeetive  cognitive  assistanee  for  the 
pilot,  reducing  mental  workload  in  challenging  and  stressful  situations. 
Since  an  IMA2G  FVL  rotorcraft  would  have  all  the  underlying 
eharaeteristies  of  an  optionally  manned  aircraft,  (whether  it  was 
designated  as  such  or  not)  the  machine  could  take  over  vehicle 
management  and  respond  dynamically  if  the  pilot  was  ineapaeitated  or  not 
responding  correctly  to  flight-envelope  warnings. 

Any  one  of  these  improvements  would  be  weleome  on  their  own;  taken  together, 
the  synergistie  effect  may  be  even  greater  than  the  sum  of  the  individual  parts. 

a.  Impact  Assessment  for  Safety  and  Survivability 

It  should  be  emphasized  that  despite  all  these  potential  advances,  FVL  aireraft 
will  still  be  required  by  the  nature  of  their  missions  to  fly  low,  slow,  and  in  elose 
proximity  to  threats  on  the  ground  or  the  oeean  surface  -  and  often  in  the  hours  of 
darkness  or  in  poor  weather.  In  other  words,  even  with  the  full  suite  of  IMA2G-enabled 
survivability  enhancements  deseribed  above,  flying  a  military  helicopter  will  never  be 
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That  being  said,  our  findings  indicate  with  a  high  degree  of  confidence  that 
IMA2G  would  have  a  strongly  positive  effect  on  the  relative  safety  and  survivability  of 
FVLFOS  aircraft. 

7.  UAS  Interoperability 

Interoperability  has  been  a  strong  selling  point  for  vendors  of  military  equipment 
ever  since  the  Goldwater-Nichols  Reform  Act  of  1986  ushered  in  the  modern  era  of 
“Jointness”  for  the  U.S.  armed  forces.  In  recent  years,  the  focus  of  interoperability  has 
grown  in  scope  to  include  the  ability  to  work  with  autonomous  or  unmanned  military 
platforms.  This  has  led  to  a  new,  high-visibility  concept:  manned-unmanned  teaming,  or 
MUM-T.  A  U.S.  Army-led  initiative  to  develop  a  standard  Joint  MUM-T  interface  is 
(not-coincidentally)  co-located  with  FVL  program  activities  at  the  Redstone  Arsenal  in 
Huntsville,  Alabama.  Though  the  programs  are  not  formally  connected,  there  are  clearly 
common  threads  of  effort.  The  FVL  ICD  states  that  “applicable  FVL  FoS  platforms  must 
control  unmanned  systems  up  to  a  Level  of  Interoperability  (LOI)  5”  (US  Department  of 
the  Army  [USA],  2011,  p.  3).  According  to  the  latest  revision  of  MUM-T  standards,  LOI 
5  entails  “Full  control  of  the  UAS,  including  take-off  and  landings”  (Baxter  & 
Eschenbach,  2014). 

The  latest  version  of  the  Boeing’s  Apache  attack  helicopter,  the  AH-64E 
Guardian  has  been  extensively  upgraded  with  IMA-style  mission  systems,  and  is  now 
capable  of  supporting  LOI  3  “Control  of  the  camera  and  sensors  on  the  UAS”  and  even 
limited  LOI  4  “Control  of  the  flight  path  and  payloads”  with  several  common  tactical 
unmanned  aerial  vehicles.  A  full  IMA2G  implementation  on  the  EVL  may  not  be 
necessary  to  achieve  the  desired  level  of  interoperability,  but  it  will  greatly  facilitate  it. 
There  is,  after  all  a  large  capability  gap  between  limited  in-flight  control  of  a  UAV,  and 
full  mission-teaming  from  take-off  to  landing.  Software-defined  avionics  supports  the 
information  sharing,  data-fusion,  and  cross-domain  functionality  required  to  make  the 
most  of  such  an  arrangement.  Additionally,  the  common  virtual  environment  that  would 
form  the  backbone  of  manned  EVE  variants  would  be  identical  to  that  found  on 
unmanned  or  optionally-piloted  variants;  strengthening  the  connection. 


64 


Whether  or  not  it  is  designated  as  sueh,  any  FVL  aireraft  built  atop  an  advaneed 
IMA  arehiteeture  would  have  all  the  inherent  eharaeteristies  of  an  optionally-piloted 
vehicle.  The  fact  that  all  or  nearly  all  mission-system,  navigation  and  VMS  controls 
would  be  part  of  an  integrated,  software  defined  (and  thus  software-controllable)  system, 
places  the  pilot  in  the  position  of  decision  executive  vice  integrator-operator.  Separation 
of  physical  I/O  from  avionics  functions  means  that  those  executive-inputs  could  just  as 
easily  come  from  an  external  data-link,  or  from  the  aircraft’s  own  autonomous  central 
control  authority  as  from  switches  and  levers  in  the  cockpit.  Manned  aircraft  based  on 
federated  systems  can  be  turned  into  drones  -  we  have  been  doing  so  for  decades  with 
obsolete  fighters  used  for  missile  tests  -  but  not  with  level  of  sophistication  needed  to 
operate  as  an  integrated  combat  or  ISR  asset.  IMA2G  would  allow  any  FVL  to  turn  into  a 
UAS,  in  the  field  -  or  even  in  the  air  -  as  necessary.  No  physical  modification  of  the 
airframe  or  avionics  would  be  required;  rather  than  mere  interoperability,  such  an 
architecture  would  establish  interchangeability  between  manned  and  unmanned  systems. 

a.  Impact  Assessment  for  UAS  Interoperability 

Our  findings  indicate  unequivocally  that  there  is  a  strong  alignment  between 
advanced  IMA  architectures  and  teaming/interoperability  with  unmanned  platforms.  For 
the  purpose  of  this  study  we  assess  the  impact  as  strongly  positive. 

8,  FVL-IMA2G  Impact  Study  Summary 

Table  9  summarizes  the  alignment  and  impact  comparison  between  FVL  program 
goals  and  IMA2G  attributes.  In  general,  we  find  the  potential  benefits  of  IMA2G 
architecture  to  be  supportive  or  strongly-supportive  of  nearly  all  FVL  mission  goals  - 
even  those  that  only  tangentially  involve  aircraft  avionics.  The  only  area  we  examined 
that  was  not  robustly  and  conclusively  supported  is  timely  development.  Although 
several  associated  aspects  of  IMA2G  (reduction  of  unique  hardware,  open-source 
standards  for  software,  model-based  systems  engineering,  etc.)  may  contribute  in  the  long 
term  to  a  more  efficient  acquisition  path,  the  complex  nature  of  the 
technical/organization/cultural  barriers  that  must  first  be  overcome  precludes  us  from 
being  overly  optimistic  in  our  assessment. 
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Table  9.  Impact  of  IMA2G  characteristics  on  FVL  progiam  goals 


Desired 

Attribute: 

EMA2G 

Impact 

Findings/Justification 

Performance/ 

Payload/Rauge 

Strongly 

Positive 

Siippoits  aircraft  empty  weight  reductions  of  7%  or  more. 

Synergistic  effects  contribute  to  reductions  in  tveight,  and  drag  of  the  entire  aircraft. 

SWAP  gains  in  avionics  can  be  traded  for  range,  speed,  hover  perfonnance.  or 
weapons/caigO' passengers 

Mission 

Capability/ 

Flexibility 

Strongly 

Positive 

Sofhvare-define  avionics  may  be  required  to  achieve  advanced  capabilities  for 
sensor  fusion,  weapons  integration,  and  partial  automation  specified  in  FVL  program 
ICD. 

Attempts  to  achieve  desired  functionality  without  advanced  IMA  will  be  result  in 
excessive  SWAP  for  mission  systems,  and  thus  compromise  performance  goals. 

Manpower/ 

Training 

Positive 

IMA2G  should  facilitate  maintenance  and  reduce  manpower  footprint. 

Reduced  maintenanee  manpower  may  be  partially  off-set  by  a  requirement  for  more 
highly-skilled  technicians. 

Timely 

Development 

NeutraF 

Indetemiinate 

Remaining  technical  challenges  will  take  time  to  overcome. 

Complex  requirements  will  take  time  to  validate  and  test 

Complexity  factor  partially  or  wholly  mitigated  by  adoption  of  model-based  systems 
design,  testing  and  certification. 

Open  source  deselopment  of  mission  software  may  speed  up  design  cycle. 

Reduced  Life- 
Cycle  Costs 

Positive 

IMA  systems  easier  and  less-expensive  to  upgrade 'maintain 

Open  source  development  can  increase  competition  between  vendois  or  allow 
repurposing  of  existing  or  COTS  program. 

IMA2G  would  likely  reduce  FVL’s  reliance  on  expensive  proprietary  systems 

Safety  and 

Survivability 

Strongly 

Positive 

IMA2G  avionics  allows  resiliency  and  fault-tolerance  greatly  exceeding  Federated 
Systems. 

IMA2G  supports  integration  and  sensor  fusion  for  advanced  counter  measures,  and 
cognitive  decision  aiding. 

IMA2G  is  easier  to  upgrade  with  new  software  hardw'are,  allowing  the  FVLFOS  to 
keep  up  with  development  of  anti-aircraft  weaptons. 

UAS  Teaming 

Strongly 

Positive 

The  sharing  of  a  conmion  avionics  systems  architecture  between  maimed  and 
umnanned  FVL  variants  would  faeilitate  data-excliange  and  operational  teaming. 
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V.  SYNTHESIS 


A,  ASSESSMENT 

Taken  as  a  whole,  the  material  presented  in  the  Chapters  II  and  IV  of  this  study 
leads  to  several  distinct  conclusions.  First,  the  prevalent  trend  within  the  avionics 
industry  is  Integrated  Modular  Avionics,  with  technology  and  competitive  pressure 
favoring  the  emergence  of  advanced  IMA2G-like  architectures  within  the  next  5  to  10 
years.  These  architectures  will  be  distinguished  from  current  state-of-the-art  systems  by 
high  degrees  of  virtualization  and  extremely  limited  hardware  specialization.  They  will 
employ  multi-core  processors,  high-speed  deterministic  Ethernet,  and  will  be  designed, 
tested,  and  certified  using  a  data-model-driven  paradigm.  The  convergence  of  functional 
domains  in  these  second-generation  IMA  designs  will  reduce  (or  in  some  case,  eliminate) 
the  gap  between  manned  and  unmanned  platforms. 

From  our  alignment  comparison  in  Chapter  IV,  it  is  clear  that  key  attributes  and 
outcomes  of  the  Future  Vertical  Fife  program  are  strongly  supported  by  the  projected 
benefits  of  the  IMA2G  technology.  As  a  consequence  of  this  fact,  as  well  as  the 
marketplace  trends  described  previously,  system  architects  are  already  attempting  to 
incorporate  IMA2G-like  technologies  into  the  Joint  Common  (avionics)  Architecture  for 
the  FVF. 

So  where  do  these  intermediate  conclusions  leave  us  in  our  assessment?  Is  it 
already  a  foregone  conclusion  that  the  FVF  will  employ  software-defined  mission- 
systems  with  converged  VMS?  We  have  already  established  that  the  ambitious 
requirements  written  into  the  FVF  ICD  make  IMA2G  a  natural  fit,  but  is  there  anything 
outside  those  explicit  requirements  that  might  counter-indicate  that  choice?  Have  we 
considered,  for  instance,  the  sum-total  attributes  that  a  fleet  of  such  aircraft  would  display 
in  operational  service?  Are  there  any  objectionable  second  or  third-order  effects  that  may 
result  from  these  attributes?  If  so,  how  might  these  effects  be  countered  or  mitigated 
against?  The  remaining  portion  of  this  thesis  will  be  dedicated  to  proposing  speculative, 
but  well-grounded  answers  to  these  questions,  and  stimulating  further  research. 
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1. 


Is  IMA2G  inevitable? 


In  the  long-term,  our  findings  indieate  no  reason  to  believe  that  the  eurrent  trend 
toward  inereasingly  software-defined  avionics  will  abate  or  reverse.  This  forecast 
progression  will  eventually  lead  to  flying  IMA2G-like  architectures  in  production  civil 
and  military  aircraft.  That  being  said,  it  is  not  certain  yet  to  what  extent  the  FVL  program 
will  participate  in,  or  contribute  to  that  trend.  In  our  interview  with  Boeing  JCA  architect 
Tom  Du  Bois,  he  stressed  that  development  efforts  are  purely  experimental  and 
conceptual  at  this  point  -  meaning  that  a  great  deal  could  change.  The  Joint  services 
could,  for  instance,  decided  to  scale  back  some  of  the  more  technically  ambitious 
wording  in  the  FVL  program  documents,  allowing  room  for  a  less-integrated,  off-the- 
shelf  solution  to  the  identified  capability  gaps.  To  offer  one  example,  scaling  back  the 
UAS  interoperability  requirement  to  Level  4,  (limited  in-flight  and  mission  package 
control),  is  already  achievable  with  partial  IMA  in  refitted  AH-64  Apaches.  If  the 
requirement  to  build  unmanned  and  optionally  manned  variants  with  the  same  common 
avionics  architecture  is  also  relaxed  or  omitted,  it  would  greatly  reduce  the  amount  of 
system-wide  integration  and  abstraction  required.  Second-Generation  IMA  might  not  be 
necessary  at  all. 

In  light  of  the  pervasive  technology  trend  evident  in  the  avionics  industry  (and 
elsewhere)  toward  converged,  software-defined  systems,  it  may  not  be  wise,  however,  for 
the  FVL  program  to  bypass  this  emerging  paradigm.  The  life-cycle  of  major  military 
systems  has  grown  steadily  longer  in  past  decades,  in  spite  of  the  apparent  acceleration  of 
consumer  technology  advances.  Where  once  the  nation’s  defense  relied  upon  the  cutting- 
edge  systems  that  were  well-beyond  anything  available  to  the  general  public  in  terms  of 
sophistication,  the  situation  has  utterly  reversed  itself  now.  The  recent  push  for 
Commercial-Off-The-Shelf  (COTS)  technology  adoption  for  DOD  applications  has  as 
much  (or  more)  to  do  with  performance  as  it  does  with  cost-savings. 

An  argument  can  be  made  that  military  technology  must  of  necessity  follow  a 
more  conservative  path  than  consumer  products,  as  the  security,  reliability,  and 
survivability  requirements  for  military  applications  are  much,  much  more  stringent. 

Allowing  front-line  aircraft  to  lag  excessively  behind  the  state-of-the-art  in  terms  of 
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computing  power  and  network  teehnology  eould  have  severe  eonsequenees  for  the  eost  of 
support  and  serviee-life  extensions  though.  It  is  not  diffieult  to  envision  a  seenario  in 
whieh  the  first  operational  FVL  variants  reaeh  squadron  serviee  in  2035  with  basie  IMA 
arehiteetures  eomparable  to  what  Boeing  and  Airbus  were  delivering  to  their  eustomers 
twenty-five  years  earlier.  In  that  case,  the  DOD  might  find  itself  as  the  sole  remaining 
eustomer  for  outdated  proeessors  and  network  technology.  Since  foreign  military  sales 
will  no-doubt  be  an  important  sueoess-metrie  for  the  FVL  program,  one  must  ask  how 
eompetitive  sueh  rotoreraft  might  be  vis-a-vis,  European  or  Asian-designed  IMA2G 
aireraft?  Indeed,  opting  for  fully  mature  teehnology  in  the  Joint  Common  Arehiteeture 
seems  sensible  and  eonservative  now,  but  by  the  mid-eentury  mark,  we  eould  well  regret 
that  deeision. 

2,  Operational  Effects 

In  order  to  projeet  meaningfully  upon  the  operational  impaets  of  advaneed  IMA  in 
future  rotary  wing  assets,  it  is  neeessary  to  embraee  the  totality  of  the  picture  and 
eonsider  the  charaeteristies  of  the  end  product:  the  aireraft  itself.  There  will  be  some 
aspeets  of  IMA2G  teehnology  itself  that  have  direct  consequences;  but  many  others  will 
simply  be  an  effect  of  the  capabilities  that  IMA2G  allows.  If  the  latter  seems  like  an 
unwarranted  digression  in  an  otherwise  teehnieal  analysis,  it  ean  be  argued  that  deeisions 
on  military  teehnology  should  always  be  made  with  knowledge  and  forethought  of 
possible  seeond-order  effeets.  Doing  otherwise  risks  opening  new  eapability  gaps  even  as 
we  sueeeed  in  elosing  existing  ones. 

A  wider  systemie  view  is  essential.  An  aireraft  like  the  FVL  (with  or  without 
IMA2G  teehnology)  must  funetion  as  a  eomponent  of  other,  larger  systems.  Upgrading 
and  enhaneing  one  eomponent  of  a  eomplex  system  often  ereates  new  points  of  strain  or 
limitation  elsewhere.  There  is  no  doubt  that  a  Joint  foree  fleet  of  IMA2G-equipped  FVL 
rotoreraft  would  offer  impressive  eapabilities  and  address  many  of  the  shortfalls  and 
limitations  of  eurrent  (federated-systems)  helieopters,  but  those  enhaneed  eapabilities  are 
likely  to  shift  points-of-failure  elsewhere.  If  known  in  advanee  or  antieipated,  the  ripple 


69 


effects  of  implementing  new  technology  can  be  planned  for  and  mitigated.  Waiting  for 
such  effects  to  actually  materialize  before  considering  the  impact,  however,  is  ill  advised. 

As  an  outgrowth  of  our  research  on  the  technology  of  software-defined  avionics 
and  mission  systems,  we  have  developed  several  matrices  of  operational  and  tactical 
impacts,  likely  consequences  or  ripple-effects  (both  positive  and  negative),  and  proposed 
mitigation  strategies  where  appropriate.  The  list  is  in  no  means  exhaustive;  yet  exploring 
each  item  in  detail  would  still  be  beyond  the  scope  of  this  study.  Our  purpose  in  including 
them  is  purely  to  suggest  further  lines  of  research,  and  perhaps  paint  a  more 
comprehensive  view  of  how  we  see  advanced  IMA  taking  the  DOD’s  rotary  wing  fleet  in 
the  future.  Our  speculations  will  be  further  refined  in  an  operational  vignette  to  follow. 

a.  Extended  Aircraft  Availability 

In  Table  10,  we  compare  the  obvious  positive  operational  consequence  of  higher 
mission-availability  rates,  with  the  less-obvious  (but  no-less  significant)  second-order 
effects  of  that  increased  availability.  The  underlying  assumption  is  that  commanders  will 
continue  to  utilize  all,  or  nearly  all,  of  the  available  rotary-wing  services  at  their  disposal 
-  even  as  that  notional  capacity  increases. 

The  primary  concern  here  is  that  the  human  element  (both  aircrew  and  support) 
will  be  stretched  dangerously  thin.  This  hazard  must  be  considered  particularly  probable 
in  the  context  of  pressure  on  the  DOD  to  reduce  its  manpower  footprint.  Making  a  value- 
based  decision  on  airborne  services  versus  manpower  costs  is  essential  here:  if  the  Joint 
services  benefit  from  increased  value-per-dollar  expended  on  rotary  wing  aircraft  (due  to 
increased  reliability/decreased  maintenance),  they  must  be  prepared  to  pay  for  at  least  a 
portion  of  that  added  value  by  supplying  sufficient  human  capital  to  sustain  the  desired 
op-tempo.  If  human  costs  are  deemed  prohibitive  beyond  a  certain  point,  then  the  only 
sustainable  long-term  solution  is  to  give  up  some  of  the  potential  benefit.  IE:  cut  back 
flight  hours  to  fit  the  new  limiting  factor:  personnel. 
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Table  10.  Operation  impact:  extended  aircraft  availability 


IMPACT/CHANGE 

Increased  aircraft  availability  and  FMC  Rate 

POSITIVE 

CONSEQUENCES 

•  Fewer  aucraft  reqirired  to  meet  mission,  redirces  total 
prociuemeut  cost  and  footprint  of  deployed  force. 

•  Operatiorral  plarming  less  constrained  by  aircraft 
availability. 

•  Enables  reduced  maintenance  manning,  and 
component  replacement  costs. 

•  Aircraft  are  safer  to  operate,  with  fewer  in-flight  or 
on-deck  aborts  dire  to  eqrripment  faihue. 

ADVERSE 

CONSEQUENCES 

•  hrcreased  availability  pirts  aucrews  at  additional  risk 
for  fatigrre  if  crew  numbers  are  not  hrcreased 
proportionately. 

•  Enhanced  op-tempo  puts  additional  strain  on  ancillary 
srrpport  services,  srrch  as  tower  and  flight  deck 
persomiel. 

MITIGATION 

STRATEGIES 

•  Be  prepared  to  increase  aucrew  maruiing  in  near¬ 
proportion  to  the  unprovement  in  FMC  rates. 
Deployed  rrnits  aheady  operate  at  or  near  safe  margins 
for  crew  day/  crew  rest. 

•  Consider  adjrrsting  air-capable  ship  manning  to  enable 
srrstamed  24-7  flight  srrpport  for  rotary  wing  assets 
(marmed  and  immauned). 

b.  Enhanced  Mission  Capability 

Table  11  projects  that  the  combination  of  IMA2G-based  mission  systems  agility, 
UAS  interoperability,  and  the  increased  range,  speed,  and  payload  of  the  FVL  platfoiin  is 
likely  to  generate  new  or  expanded  mission-sets  for  the  rotary-wing  fleet.  Hehcopters 
cimently  make  up  over  50%  of  the  total  aucraft  in  the  Jomt  service  inventory  —  compar  ed 
to  less  than  20%  for  fixed-wing  attack/strike  aucraft.  (“U.S.  Military  Strength,”  2015)  It 
is  reasonable  to  expect  that  FVL  variants,  especially  the  medium-lift  platform,  will  also 
be  birilt  in  large  uitmbers.  Assuming  a  reasonably  srrccessfirl  development  program,  this 
shoitld  bringing  FVL  per-imit  costs  down  relative  to  comparably  advanced  fixed-wing  jet 

aucraft,  which  ahnost-siuely  be  pruchased  in  smaller  qrrantities.  Tliis  fact  opens  irp  the 
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possibility  that  certain  force-application  missions  that  have  traditionally  been  associated 
with  such  assets  may  begin  to  migr  ate  to  newly-capable  veitical-lift  aucraft.  Even  if  they 
are  judged  less-effective  at  those  missions  on  a  per-aircraft-soitie  basis,  their  greater 
nimierical  availability,  along  with  their  capacity  to  work  closely  with  tactical  drones,  and 
their'  reduced  reliance  on  well-developed  airfields  or  aircraft  carriers  will  make  them  an 
attractive  alternative  in  many  cases. 


Table  11.  Operational  impact:  enhanced  mission  capability 


IMPACT/CHANGE 

Broadened  mission-capability,  flexibility,  outreach 

POSITIVE 

• 

Operational  plarmers  less  constrained  by  available 

CONSEQUENCE 

assets,  since  aircraft  can  be  reconfigiued  via  software 
for  specialized  mission  sitpporf. 

• 

New  sensor-ftrsion  ISR  and  commimication 
capabilities  for  Joint  Forces  resirlting  in  higher  SA  for 
both  aircrew  and  commanders  rrear  the  tactical  edge 

• 

Ability  to  rapid  adopt  new  commrmications  paths, 
sensors,  or  weapons  as  they  become  available 

ADVERSE 

• 

Capacity  for  multi-mission  flexibility  may  firrther 

CONSEQUENCE 

erode  specialty  skills  of  aircrew.  “Jack  of  all  trades, 
master  of  none”  scenar  io. 

• 

New  mission  sets  may  evolve  for  rotary-wing  assets 
in  competition  with  existing  capabilities,  leading  to 
inter-  and  intra-service  rivahy. 

MITIGATION 

• 

Consider  longer  dirration  initial  fleet  toms  for  aircrew 

STRATEGY 

to  allow  for  extended  exper-ience  with  mirltiple 
mission-types. 

• 

Review  and  re-align  as  mission-sets  for  advanced 
rotary-wing  platforms  at  appropriate  to  then 
newfoimd  capabilities. 

• 

Leverage  the  rnission-eqiripment-as-tactical-simulator 
concept  enabled  by  IMA2G  to  assist  irr  proficiency  for 
deployed  crews 

On  order  to  make  best  use  of  available  aviation  components,  including  the 

FVLFOS,  we  anticipate  the  need  for  a  serious  review  and/or  realignment  of  mission 

priorities  for  various  platforms.  It  seems  likely  that  a  projected  ftrtme  of  limited  wars, 

72 


counter-insurgencies,  and  proliferated  anti-access/area-denial  (A2AD)  weapons  will 
favor  the  flexible  capabilities  of  advanced  rotary-wing  aircraft,  closely  teamed  with 
unmanned,  or  optionally  manned  platforms. 

Of  course,  the  inherent  capability  of  a  given  aircraft  to  fly  of  a  multitude  of 
missions  does  not  mean  that  the  majority  of  its  crews  are  eompetent  to  exeeute  100%  of 
those  missions  100%  of  the  time.  The  reality  of  personnel  rotation,  work-up  cycles,  and 
fiscally  constrained  budgets  for  training  virtually  preclude  this  from  being  the  case.  In  the 
largely-bygone  era  of  single-mission  military  aireraft,  pilots  and  crewmen  eould 
concentrate  their  training  and  experience  on  a  particular,  narrowly  defined  skill-set, 
usually  aehieving  a  high  degree  of  competency  as  a  result.  Modern  crews  of  multi¬ 
mission  platforms  do  not  have  that  luxury.  Though  they  generally  have  assistanee  from 
on-board  automation  to  help  make  up  for  their  lack  of  specialist  competency,  they  are 
still  required  to  remain  cognizant  of  a  very  broad  speetrum  of  tacties,  teehniques  and 
procedures.  At  a  certain  point,  as  mission-sets  continue  to  expand  and  diversify,  a  tipping 
point  could  easily  be  reached.  Again,  the  limiting  factor  becomes  the  human  element. 

Cognitive  decision  aiding  and  partial  automation  are  proposed  within  the  FVL 
ICD  to  help  address  this  “weak  link”  in  the  cockpit.  Both  of  these  services  are  robustly 
supported  by  an  advaneed  IMA2G  system,  but  there  is  perhaps  an  additional  way  that 
software-defined  avionies  eould  help:  by  ensuring  that  aircrews  are  better  prepared  for 
their  missions  in  the  first  plaee. 

High-fidelity  taetieal  simulators  have  already  proven  their  worth  as  a  training  tool 
and  are  in  many  eases  supplanting  actual  flight  hours  for  maintaining  readiness.  Due  to 
their  cost  and  large  logistie  footprint  however,  they  are  generally  in  short  supply,  and 
never  available  in  deployed  environments.  But  what  if  every  fleet  aircraft  could  function 
as  its  own  simulator?  With  access  to  the  latest  theatre  intelligence,  aircrews  eould 
rehearse  real-world  missions,  experiment  with  different  taetics,  and  then  aetually  launeh 
on  the  sortie  and  fly  it.  Afterwards,  if  deemed  useful,  the  mission  eould  be  re-flown  based 
on  reeorded  data. 

The  highly-abstract  nature  of  IMA2G  makes  this  a  very  real  possibility.  Most 

avionies  and  mission-systems  funetions  would  exist  as  hosted  virtual  maehines  on  the 
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server  network,  with  their  only  connection  to  I/O  and  effectors  provided  through  the 
services  of  the  hypervisor.  A  special  mode  could  be  enacted  in  which  the  hypervisor  re¬ 
routed  the  majority  of  those  outbound  messages  to  a  hosted  simulation  program.  Loaded 
with  the  scenario  of  choice,  the  program  would  define  the  virtual  world  that  the  other 
hosted  aircraft  systems  would  “see.”  From  the  aircrew’s  perspective,  cockpit 
functionality  would  be  identical  to  what  they  would  experience  in  an  actual  flight. 
External  visuals  could  be  provided  (optionally)  by  a  kit  of  deployable  projection  screens, 
and  multiple  aircraft  and  UAV’s  could  be  linked  together  to  practice  cooperative  tactics. 
(See  Appendix  A  for  a  notional  depiction  of  this  set-up.)  Minor  maintenance  and 
servicing  could  even  be  accomplished  concurrently  with  the  simulator  event,  in  order  to 
assure  the  aircraft  was  ready  to  launch  immediately  afterwards.  Alternately,  airframes 
that  are  currently  grounded  for  repairs  might  in  some  cases  still  be  usable  as  simulators, 
providing  value  even  while  not  available  for  flight  ops. 

c.  Manned/Unmanned  Aircraft  Convergence  and  Teaming 

Of  course,  any  discussion  of  human  pilots  as  a  “weak  link”  in  an  otherwise 
highly-capably  airborne  system  begs  a  further  question:  why  put  a  warm  body  in  the 
cockpit  at  all?  Certainly,  for  some  missions — especially  those  falling  under  the 
description  of  “dull,  dirty,  or  dangerous” — ^unmanned  systems  are  probably  the  best 
choice.  In  a  fully-developed  future  battle-space  however,  the  more  likely  scenario  is  close 
teaming  and  interaction  between  UAVs  and  manned  aircraft.  MUM-T,  as  previously 
described,  is  strongly  supported  by  advanced  IMA  mission-systems  architecture.  In  Table 
12,  we  list  some  of  the  prominent  advantages  that  might  be  gained  by  the  convergence 
and  teaming  of  manned  and  unmanned  FVL  variants,  and  the  down-stream  effects  could 
possibly  develop. 

Contrary  to  the  starry-eyed  optimism  envisioned  in  the  DOD’s  Unmanned  System 
Integration  Roadmap  (2013),  we  do  not  feel  that  the  increased  utilization  of  UAVs  to 
provide  round-the-clock  aerial  services  is  a  silver-bullet  solution  to  the  Joint  services 
current  manpower  concerns.  In  the  context  of  optionally  piloted  FVL  variants,  the  cost- 
per-fiight  hour  is  likely  to  be  exactly  the  same  whether  the  craft  is  manned  or  not.  The 
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decision  of  what  mode  to  employ  it  in  must  be  driven  by  factors  other  than  cost- 
containment. 

Employment  of  optionally-maimed  rotorcraft  must  also  be  considered  in  light  of 
adversaiy  perceptions.  Opposing  forces  under  siuveillance  by  FVL  aucraft  will  often 
have  little  way  of  knowing  whether  or  not  there  is  a  human  crew  on  boaid,  and  the 
assumption  (one  way  or  the  other)  could  mean  a  radically  different  reaction.  Shooting 
down  a  dioue  might  be  considered  an  acceptable  escalation  of  ciuient  tensions,  whereas 
attacking  a  manned  aircraft  would  not;  thus  a  dioue  might  be  protected  by  the  perception 
that  it  could  be  manned.  Conversely,  a  manned  crew  could  be  targeted  based  on  the 
mistaken  belief  that  then  aircraft  is  “just  a  di  one.” 


Table  12.  Operational  impact:  manned/immauned  convergence/teaming 


IMPACT/CHANGE 

UAS  Teaming  /  Convergence  of  Manned/Unmanned  Systems 

POSITIVE 

CONSEQUENCE 

•  Powerfiil  force  multiplier.  Enables  extended  air- 
mission  coverage. 

•  Enables  new  tactics  that  will  reduce  risk  to  manned 
aircrews  while  still  extending  liigh-quality  support  for 
CAS  mission  and  OTH-T. 

•  Human  crews  can  be  “saved”  for  missions  that 
significantly  benefit  from  their  presence.  Missions 
that  are  just-as-well  conducted  autonomously  or 
remotely  need  not  be  manned. 

•  Optionally-piloted  aircraft  provide  a  imified  asset  - 
with  common  maintenance  support  -  for  both  manned 
and  uumaimed  missions. 

•  The  manned  or  unmanned  status  of  optionally-piloted 
FVL  aircraft  will  be  opaque  to  potential  adversaiy 
forces.  They  may  be  more  reluctant  to  engage  the 
aucraft  due  to  the  perception  of  more  severe 
consequences  for  destroying  a  manned  aircraft. 

ADVERSE 

CONSEQUENCE 

•  Additional  roimd-the-clock  strain  on  aircrews  due  to 
the  need  to  supervise  immamied  FVL  mission  in 
addition  to  maimed  sorties. 

•  Reduced  flight  horns  and  actual  “stick  time”  erodes 
basic  aircrew  competency  and  Esprit  d’Coips. 

•  Without  aii'crew-diiveu  limits,  commanders  will 

75 


fMPACT/CffANGE 

UAS  Teaming  /  Convergence  of  Manned/Unmanned  Systems 

demarrd  24-hoiu’  flight  operations,  straining  sirpport 
services  like  maintenance,  ATC,  and  flight-deck 
crews. 

•  Plarmers  may  be  tempted  to  sirpplaut  qiralified  pilots 
with  less-expensive,  jimior  persormel  for  irmuauned 
FVL  missions;  loss  of  experience  may  resirlt  in  poorer 
mission  performance. 

•  A  marmed  aircraft  may  be  targeted  on  the  assirmption 
that  it  is  “just  a  drone.” 

MfriGATION 

STRATEGY 

•  Be  prepared  to  increase  aircrew  and  sirppor1-crew 
marming  in  order  to  sirpporf  24/7  flight  ops. 

•  Develop  new  TTP  for  UAS-manned  aircraft  teaming, 
established  firm  policy  giridauce  on  what  urission-sets 
reqitire  on-board  hitman  crew  for  execirtion. 

d.  System  Sofhvare  Complexity 

Software  and  overall  system  complexity  is  a  fact  of  life  for  modem  aircraft,  and 
IMA2G  architectmes  will  be  far  more  complex  than  anything  flying  today.  The  open 
question  is  whether  the  cleverness  of  the  system’s  open-aichitectm  e  and  MILS-compliant 
foimdation  will  be  euougli  to  help  mitigate  (or  even  reverse)  the  adverse  consequences  of 
that  logical  complexity,  or  whether  it  will  only  make  things  worse.  One  way  or  another, 
robust  seciuity  needs  to  be  fimdamental  to  the  design  of  the  FVL’s  mission-systems;  not 
merely  assumed  away  or  added  on  afterwards  as  a  patch. 


Table  13.  Opera tiorral  impact;  system  software  complexity 


IMPACT/CHANGE 

Software  Complexity,  Functionality  and  Authority 

posmvE 

CONSEQUENCE 

•  Software-driven  fiurctionality  will  be  easier  to 
itpgrade  drnirrg  vehicle  life-cycle,  allowing  rapid 
capability  evohrtiou 

•  Aircraft  will  be  capable  of  providing  autorromoirs 
sirpport  to  human  crew,  redircing  workload  in  critical 
combat  sitiratious. 

•  Every  onboard  fimction  can  be  tracked  arrd 
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IMPACT/CHANGE 

Softw’are  Complexity,  Functionality  and  Authority 

monitored;  feeding  into  proactive  condition-based 
maintenance,  and  maintenance-availability-based 
sortie  planning. 

•  Aircraft  will  be  easier  and  safer  to  fly  at  tire  margins 

of  perfonnarrce,  perhaps  approaching  the  ideal  of  a 
“rmcrashable”  aircraft 

ADVERSE 

CONSEQUENCE 

•  Need  for  advanced  skill-set  to  troirbleshoot  problems 
with  IMA2G  aircraft  avionics  coirld  make  fiont-line 
Joint  forces  more  reliarrt  on  expensive  contractors  for 
srrpport. 

•  hr  the  event  that  an  FVL  aircraft  is  captiued  by  a 
sophisticated  adversary,  the  enormous  qirantity  of  data 
on  board,  mrtch  of  it  stored  in  open-soirrce  COTS 
applications  may  be  a  significant  liability. 

•  Near  100%  of  aircraft  fimctionality,  mchrding  flight 
and  weapon  systems  will  be  potentially  vithierable  to 
malicious  code  implanted  by  a  sophisticated  enemy. 

•  A  rnalfimctioning  or  enemy-cormpted  firll-airthority 
IMA  system  coirld  take  control  away  from  the  human 
crew  with  tragic  and  devastating  consequence. 

MITIGATION 

STRATEGY 

•  hrclude  a  requirement  for  a  hard-discorurect  option  in 
the  JCA  to  restore  manned  control  in  the  event  of 
connpted  autonomous  or  external  control. 

•  Ensure  capacity  exists  within  the  system  to 
conclusively  (and  remotely)  wipe  aU  classified  and 
mission  data  from  on-board  aircraft  memory  in  the 
event  of  urmiinent  captme  by  adversary  forces. 

B.  OPERATIONAL  VIGNETTE 

The  following  is  a  hypothetical  scenario  in  which  the  presumed  characteristics  of 
an  FVL  aircraft  with  software-defined  missiorr  systems  is  imagined  in  a  poterrtial 
operational  envuonment.  The  FVL  variant  m  qirestion  is  an  optionally-marmed  mirlti- 
mission  maritime  version  in  U.S.  Navy  service.  The  presirmed  time-fiame  of  this  scerrario 
is  the  late  2030’s;  several  years  the  aucraft  has  reached  IOC.  The  backdrop  of  events  is  a 
rapidly  escalating  territorial  dispute  irr  the  Western  Pacific  over  energy  exploitation  and 
fishing  rights. 
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1,  Scenario  Background 

Seeking  an  alternative  method  to  realize  territorial  elaims  rejeeted  by  the  rest  of 
the  international  eommunity,  Country  Orange  has  apparently  resorted  to  arming  and 
assisting  separatist  rebels  on  an  island  ehain  bordering  disputed  shoal  waters.  The  Brown 
Islands  are  a  reeognized  arehipelago  of  Country  Green,  and  most  inhabitants  of  its  major 
population  eenter  eonsider  themselves  loyal  eitizens  of  Country  Green.  Country  Orange, 
however,  elaims  ethnie  and  historical  ties  to  an  oppressed  minority  population  in  the 
southwestern  third  of  the  archipelago.  Six  months  ago,  the  Brown  Islands  were  struck  by 
a  severe  typhoon,  providing  Country  Orange  the  pretext  to  establish  a  humanitarian  naval 
and  air  mission  to  the  rebel-dominated  portion  of  the  archipelago.  Since  then,  hostilities 
between  the  rebels  and  Country  Green  forces  have  escalated  rapidly.  Western  intelligence 
sources  suggest  that  Country  Orange  is  providing  military  weapons  and  training  to  the 
otherwise  isolated  rebels,  in  addition  to  food  and  relief  supplies.  Country  Green  suspects 
this  as  well,  and  has  openly  accused  Country  Orange  of  fomenting  revolution  on  the 
archipelago.  Recently,  a  Green  corvette  near  the  Brown  coast  was  destroyed  by  a 
suspected  light-weight  anti-ship  cruise  missile  fired  from  a  shore -based  TEL 
(Transporter,  Erector,  Launcher).  Rebels  claimed  responsibility,  but  all  signs  point  to 
Country  Orange  as  the  supplier  of  the  missile  system. 

In  order  to  help  arrest  further  hostilities  and  deter  Country  Orange  from 
undertaking  overt  military  action  in  support  of  the  Brown  Island  Rebels,  the  U.S.  Pacific 
Command  has  dispatched  a  combined  joint  task  force  to  the  region.  As  part  of  that  task 
force,  the  guided-missile  destroyer  USS  Chris  Kyle,  DDG-123,  is  currently  sailing  off  the 
western  edge  of  the  brown  Archipelago.  Embarked  aboard  the  Kyle  is  a  two-plane 
detachment  from  Vertical-Lift  Maritime  Strike  Squadron  Eive-One  (VMS-51)  -  the 
“Warlords”  -  out  of  Iwakuni,  Japan. 

2.  Phase  I:  Ops  Normal 

Date:  March  29,  2039 

Time;  1645L(0845Z) 

Location:  70  NM  WSW  of  Goat  Island  in  the  Brown  Archipelago. 

Threat  Warning  Condition:  Yellow 
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Weapon  Control  Status:  Tight 

Warlord  710  flew  a  rock-steady  approach  to  the  back  of  the  USS  Chris  Kyle, 
touching  down  and  dropping  its  landing  probe  dead-center  in  the  Recovery  &  Securing 
Device  (RSD)  “trap.”  It  was  just  the  sort  of  landing  one  would  expect  from  a  well- 
seasoned  crew  on  the  back-end  of  a  long  deployment.  Except  for  one  small  detail. . .  The 
cockpit  and  cabin  of  Warlord  710  was  presently  unoccupied. 

Detachment  Four  Officer-in-Charge  (OIC)  “JD”  watched  the  recovery  from  the 
right  seat  of  the  Det’s  other  aircraft,  Warlord  704,  orbiting  a  quarter-mile  off.  Tough  act 
to  follow,  he  thought  to  himself.  The  only  way  of  really  competing  with  the  smoothness 
of  an  automated  FVL  approach  was  to  add  a  little  style;  come  in  fast,  flare  at  the  last 
minute  -  and  hope  you  didn’t  “goon  it  up”  and  make  a  fool  of  yourself.  Most  of  the  time 
he  managed  to  pull  that  off  pretty  convincingly,  but  then  again,  his  first  fleet  tour  had 
been  spent  wrestling  overweight,  nervous-handling  conventional  helicopters  onto  small 
decks  like  this — without  the  benefit  of  fly-by-wire  controls  or  the  safety-net  of  an 
automatic  approach  mode. 

Those  old  MH-60Rs  couldn’t  fly  their  own  functional  check-flights  (FCFs)  either, 
come  to  think  of  it — ^which  was  exactly  what  Warlord  710  had  just  done.  After  a  few 
minutes  of  spinning  on  deck,  the  unmanned  aircraft  shut  down  and  began  folding  its 
rotors.  JD’s  aircrewman  aboard  704,  AW2  Stout,  who  had  been  monitoring  the  other 
aircraft’s  flight  via  secure  data-link,  keyed  the  ICS.  “Fooks  like  710’s  up  FMC  Boss.  All 
Vibe  runs  and  final  grounds  are  within  limits.” 

“Roger,”  JD  replied,  nodding.  “I  guess  we’re  going  to  have  an  alert  aircraft 
tonight  after  all.” 

“Sir,  I  was  kind  of  hoping  we  wouldn’t,”  Stout  replied  with  his  usual  excessive 

candor. 

“Me  too.”  JD  agreed.  Things  had  been  certainly  been  heating  up  lately  in  this 
AOR.  Back  in  November,  the  Kyle  and  Det  Four  had  been  sent  down  here  to  support 
humanitarian  assistance  and  disaster  relief  (HADR)  operations  in  the  Brown  Archipelago. 
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They  had  no  idea  at  the  time  that  they  would  be  back  just  a  few  months  later,  getting  shot 
at. 

Well  strictly  speaking,  JD  clarified  to  himself,  we  didn  ’t  get  shot  at,  Warlord  710 
got  shot  at. 

Two  nights  ago,  while  flying  an  autonomous  ISR  flight  in  the  vicinity  of  Goat 
Island,  710  had  taken  small-arms  fire  from  a  rebel  gunboat.  Reacting  as  quickly  to  the 
threat  as  any  human  pilot  could  have,  the  self-flying  rotorcraft  had  managed  to  get  away 
safely,  but  returned  to  the  ship  with  a  gaping  hole  from  a  12.7  mm  machine  gun  in  one  of 
its  rotor-blades.  Replacing  that  blade  had  driven  the  FCF  today;  and  now,  after  two 
unmanned  vibration  runs,  the  machine  was  back  up  and  available  for  tasking. 

The  same  could  not  be  said,  unfortunately,  for  the  Detachment  Maintenance 
Officer.  “Squirrel”  was  currently  laid  up  with  fractured  a  bone  in  her  left  hand.  She  had 
fallen  down  a  ladder  well  on  the  ship  while  rushing  to  inform  her  OIC  that  710  had  been 
fired  upon.  That  left  JD  as  the  only  qualified  AC  (Aircraft  Commander)  on  the  four-pilot 
det. 

Given  the  recent  spate  of  hostilities,  the  captain  of  the  Chris  Kyle  had  insisted  that 
the  Detachment  fly  an  armed  overwatch  mission  to  cover  710  during  its  FCF  runs — 
which  was  the  only  reason  why  JD  was  airborne  at  the  moment.  The  majority  of  action 
around  Goat  Island,  including  the  covert  intrusion  of  Country-Orange  vessels  into  Green 
territorial  waters  to  supply  arms  to  the  rebels,  happened  only  under  the  cover  of  darkness. 

JD  glanced  over  at  the  empty  seat  to  his  left.  Taking  advantage  of  704’ s  single¬ 
pilot  mode,  with  its  “virtual  co-pilot”  service,  he  had  been  able  to  spare  his  two  nugget 
pilots  the  boredom  of  a  daytime  drone-escort  mission;  that  way,  they  would  be  fresh  for 
tonight’s  alert,  and  could  remain  on  the  nocturnal  schedule  they  had  already  adapted  to. 
As  for  himself  and  AW2  Stout,  his  goal  was  to  be  on  deck  as  soon  as  710  was  folded  and 
stuffed  inside  the  port  hangar. 

“Green  deck,”  JD  announced  over  the  ICS.  Up  ahead  in  the  distance,  he  could 
make  out  the  green  deck  status  light  on  the  Kyle',  but  he  needn’t  have  looked  up  from  his 
instrument  console  to  know  that  he  had  been  cleared  to  land.  The  four  MFD’s  (Multi- 
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Function  Displays)  in  front  of  him  currently  showed  everything  he  needed  to  know, 
including  the  deck-status.  Courtesy  of  the  KU-band  data-link  with  the  destroyer  and  the 
attentive  services  of  his  virtual  co-pilot,  he  had  the  ships  BRC  (base  recovery  eourse) 
dialed  in,  as  well  as  a  continuously  updated  read-out  on  such  factors  as  closure-rate, 
winds-over-the-deck,  and  piteh  and  roll. 

“Hal-704,”  JD  annuneiated  into  the  mike,  summoning  his  voice-aetivated  virtual 
eo-pilot  by  its  programmed  sobriquet.  “Landing  Checklist:  shipboard  recovery.” 

At  onee,  the  NATOP  ehecklist  for  landing  operations  appeared  on  one  of  JD’s 
MFDs,  and  a  faultlessly  calm,  computerized  voice  began  methodieally  reading  eheeklist 
items.  On  eue,  JD  either  performed  the  listed  step,  or  issued  a  verbal  reply,  prompting 
“Hal”  to  do  it  himself  At  the  end  of  the  checklist,  the  computerized  co-pilot  confirmed 
that  winds  over  the  deck  were  within  limits  and  landing  gear  was  down  and  locked. 

Approximately  ninety  seconds  later.  Warlord  704  erossed  the  deek-edge  and 
alighted  seeurely  with  its  probe  in  the  RSD. 

“Try  to  beat  that  one,  Hal”  JD  mumbled  to  himself 

“Please  repeat  your  last,”  replied  the  automated  voice,  apologetieally.  “I  did  not 
understand  your  request.” 

“Disregard  Hal  704,”  JD  instructed.  “Initiate  autonomous  hand-over  eheeklist.” 

As  the  Det  Four  OIC  and  AW2  Stout  unstrapped.  Warlord  704  began  preparing 
itself  for  its  next  mission.  Tonight,  a  SEAL  platoon  was  going  ashore  via  submersible 
delivery  vehiele  to  scout  for  (and  hopefully  neutralize)  the  Orange-supplied  mobile 
ASCM  launehers  with  which  the  rebels  had  been  attaeking  Country  Green  shipping.  704 
would  provide  armed  overwatch  and  continuous  surveillance  throughout  the  night.  If  all 
went  well,  the  SEALS  would  hit  their  target  and  egress  the  same  way  they  had  come 
before  sunrise.  Until  then  though.  Warlord  710 — and  a  human  erew — would  be  on  30- 
minute  alert  for  an  airborne  extraetion. 

3.  Phase  II:  Mission  Preparation 


Time:  1830L(1030Z) 
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After  dinner  in  the  wardroom,  JD  rounded  up  his  two  nugget  pilots  and  the 
airerewmen  that  would  be  sharing  the  night’s  alert  mission  with  him.  After  eheeking  in 
with  the  ship’s  Tactieal  Aetion  Offieer  (TAO)  in  the  Combat  Information  Center  (CIC), 
and  watehing  a  few  minutes  of  live  sensor  feed  from  Warlord  704,  they  eondueted  their 
own  mission  brief  and  headed  to  the  hangar.  Per  JD’s  instruetions.  Warlord  710  was 
already  set  up  with  the  Det’s  DIVTAC  (deployable  integrated  virtual  taetieal  simulator) 
kit,  and  a  simulated  mission  emulating  an  opposed  SEAL  extraetion  from  Goat  Island 
was  loaded  and  ready  to  go. 

A  wealth  of  reeent  all-source  intelligence  and  fused  sensor  data  from  the  Navy’s 
“Big-Data”  tactical  cloud  ensured  a  high  degree  of  fidelity  in  the  simulation  model.  JD 
flew  two  ingress  and  egress  runs  apiece  with  each  of  his  nuggets  in  the  space  of  just  40 
minutes,  experimenting  with  various  routes  to  and  from  the  LZ  (Landing  Zone).  Based  on 
the  simulation  results,  he  concluded  that  his  odds  of  getting  feet-dry  for  the  pick-up 
without  being  detected  were  better  than  50-50.  Getting  back  out  again  however,  was 
going  to  be  a  bit  tricky.  By  the  end  of  the  last  run,  there  were  tracers  arcing  all  over  the 
computer-generated  night  sky,  and  JD’s  co-pilot,  Llo,  was  working  hard  to  evade. 

“You  think  there’s  really  going  to  be  that  many  of  them  shooting  at  us,”  she 

asked. 

“This  is  just  a  worst-case  scenario,”  JD  dismissed  calmly.  “Don’t  worry  about 
it... Too  much.” 

Satisfied  that  that  his  crew  was  ready,  the  Det  Lour  OIC  called  an  end  to  the 
simulator  session.  “Get  some  rest  everybody.  There’s  going  to  be  a  whole  lot  of  hurry-up- 
and-wait  before  dawn.” 

4.  Phase  III:  Alert  Upgrade 

Time:  2330L(1530Z) 

The  first  four  hours  of  this  alert  period  went  by  as  expected:  quietly.  It  was  not  the 

first  time  Det  Lour  had  been  tasked  with  such  “hurry  up  and  wait”  tasking  in  support  of 

SOL  forces  in  the  Brown  Archipelago;  and  they  usually  ended  up  sitting  on  the  bench 

82 


while  army  rotorcraft  from  the  160th  SOAR  (Speeial  Operations  Aviation  Regiment)  got 
the  actual  sortie.  JD  had  no  inkling  yet  that  tonight  would  be  any  different,  so  after 
Warlord  704  returned  for  fuel  and  re-launched  autonomously,  he  grabbed  a  workout  mat, 
stretched  out  on  the  flight  deck,  and  fell  asleep  under  the  stars. 

Not  long  before  midnight,  Flo  suddenly  shook  him  awake.  “JD!,  JD!  Sir!”  the 
lieutenant  junior-grade  spoke  in  a  frenzy.  “We  just  got  upgraded  to  a  ready-five!” 

Jarred  instantly  from  his  stupor  by  the  announcement,  JD  leapt  to  his  feet  and 
snatched  up  his  yoga  mat.  A  moment  later,  the  port  hangar  door  began  to  open,  and  the 
clamor  of  busy  sailors  spilled  out  onto  the  flight  deck. 

“Gear  up,”  he  instructed  Flo.  “I’ll  be  back  in  a  minute.” 

As  JD  rushed  past  Warlord  704,  still  folded  and  stuffed  in  the  hangar,  he  noticed 
that  the  DIVTACS  kit  was  still  installed  and  activated.  Now  though,  instead  of  acting  a 
simulator,  it  was  linked  to  the  Warlord  710,  and  the  images  projected  on  the  deployable 
view  screens  were  live  feed  from  the  other  aircraft’s  onboard  cameras.  In  theory,  710 
could  be  remotely  piloted  from  the  cockpit  of  her  sister-aircraft,  through  the  medium  of 
the  Kyle’s  data  link,  but  right  now,  it  was  only  functioning  as  a  secondary  monitoring 
station.  The  primary  mission-control  station  was  in  the  Combat  Information  Center  (CIC) 
-  and  that  was  where  JD  has  headed  now,  grabbing  his  helmet  and  vest  as  he  went. 

“Looks  like  the  SEALS  are  having  trouble  making  it  back  to  their  sub 
rendezvous,”  explained  Squirrel  as  JD  and  the  ship’s  TAO  leaned  over  her  shoulder  in 
CIC.  “Too  much  heat.” 

“I  can  see  that,”  agreed  JD.  The  sensor  feed  from  Warlord  710  was  up  on 
Squirrel’s  console.  There  was  clearly  a  firelight  in  progress  on  the  coast  of  Goat  Island. 
Glowing  arcs  of  tracers  were  crisscrossing  over  the  tropical  beach. 

“Captain  in  Combat,”  someone  announced.  A  moment  later,  the  CO  of  the  Chris 
Kyle  joined  JD,  Squirrel  and  the  TAO.  The  commander’s  first  question  was  about  the 
TELs;  he  wanted  to  know  if  the  SEAES  had  managed  to  take  them  out. 
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“Negative  Sir,”  answered  the  TAO.  “They  found  them,  but  they  ean’t  get  there 
right  now.” 

“What  about  704?”  asked  the  eaptain.  “It’s  armed.  Can  we  use  it  to  hit  the 
launehers?” 

Squirrel  field  that  question:  “Out  of  range  Sir.  704  had  to  stand  baek  when  she 
started  taking  AAA  and  MANPAD  fire.” 

“How  far  out  are  we?”  asked  JD. 

“32  nautieal  miles  from  the  beaeh,”  said  the  TAO.  “Just  outside  the  range  of  those 
cruise  missiles.” 

“Until  those  TELS  are  down,  that’s  as  close  as  you’re  getting,”  stated  the  captain 
with  a  glance  toward  JD. 

“I’ve  got  missiles  on  the  rail  on  710,  ready  to  go,”  JD  replied.  “All  I  need  is  the 

word.” 

“Unfortunately,  that’ll  have  to  come  from  the  Admiral,”  shrugged  the  captain. 

JD  wasted  no  further  time  in  CIC.  Squirrel  was  already  busy  uploading  the 
additional  intel  and  mission  information  onto  Warlord  710’s  avionics  servers.  By  the  time 
the  Det  Four  OIC  was  strapped  in,  the  aircraft  was  configured  for  dual-piloted  flight,  and 
waypoints  determined  on  the  basis  of  the  earlier  simulation  run  were  up  on  the  navigation 
screen.  The  old  saw  “Fight  like  you  train”  had  rarely  found  more  literal  expression. 

JD’s  copilot  tonight — aside  from  the  omnipresent  virtual  one  imbedded  in  the 
avionics  server — ^was  the  det’s  most  junior  aviator,  Flo;  but  the  OIC  didn’t  consider  that 
fact  a  liability.  A  fresh  set  of  eyes  in  the  cockpit  could  sometimes  be  a  vital  asset, 
especially  when  backed  up  by  some  experience  in  the  right  seat,  and  the  unblinking  eye 
of  technology  imbedded  in  the  aircraft’s  smart  systems. 

Stuck  in  CIC  with  her  broken  hand  meanwhile.  Squirrel  couldn’t  pass  up  the 
chance  to  tease  her  fellow  JO  (Junior  Officer)  over  the  data-link. 

“Ready  to  be  a  hero,  Flo-Baby?” 
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Flo  got  her  right  back  without  missing  a  beat.  “Maybe  if  you  weren’t  such  a  klutz, 
you’d  be  sitting  here  instead  of  me  tonight.  But  anyway,  I’m  sure  Hal’s  got  my  back.” 

5.  Phase  IV:  Launch  the  Alert! 

Time;  0012L(1612Z) 

With  the  aircraft  spotted  and  spread  on  the  deck,  and  the  alert  checklist  complete, 
things  got  quiet  for  a  few  minutes  aboard  Warlord  710.  Thanks  to  the  live  feed  of  video 
and  data  from  Warlord  704,  JD  and  his  crew  already  had  a  remarkably  clear  and  detailed 
tactical  picture  of  the  operating  area  on  their  MFDs,  complete  with  blue-force  position 
indicators  for  the  SEAL  platoon,  and  tracks  for  the  cruise  missile  TEES. 

“Look  -  the  TEES  are  on  the  move,”  Elo  pointed  out.  “They’re  buggin’  out.” 

JD  nodded,  watching  the  vehicles  line  up  in  a  convoy  and  start  to  drive  slowly 
westward.  It  was  exactly  the  scenario  he  had  programmed  into  his  simulation  earlier.  He 
knew  already  that  if  the  launchers  managed  to  reach  the  jungle-covered  highlands  seven 
miles  up  the  road,  they  would  be  very  difficult  to  root  out;  but  if  he  could  launch  right 
now,  there  was  still  time  to  engage  those  TEES  and  meet  the  SEALS  at  their  back-up 
extraction  point.  They  had  just  practiced  it  in  the  DICTACS. 

As  if  on  cue,  a  new  message  popped  up  in  the  secure  command  chat  that  JD  was 
monitoring  on  one  of  his  ancillary  screens:  “CJTE  says:  Launch  Warlord  710,”  it  read. 
A  few  seconds  later,  the  tactical  controller  echoed  the  command  over  the  data-link  voice 
channel.  By  then  the  crew  was  already  working  their  checklists  through  Hal  to  start  the 
engines  and  prepare  for  take-off.  While  they  were  waiting  for  the  ship  to  turn  into  the 
wind  and  pass  green  deck,  JD  noticed  another,  follow-on  message  from  the  CJTE  Battle 
Watch.  “Sniper  helos  directed  to  neutralize  TELs  on  Goat  Island  prior  to  SEAL 
extraction.  160  SOAR  is  avail  for  p/u  of  team  in  40  min  if  required.”  Sniper,  was  the 
local  callsign  for  the  USS  Chris  Kyle,  of  course.  JD  grinned  to  himself  as  the  deck  status 
light  turned  green.  It  looked  like  he  was  going  to  get  the  opportunity  to  translate  his 
simulator  run  into  reality  after  all.  Let’s  try  not  to  goon  this  was  up  so  bad,  he  thought  to 
himself  silently. 


85 


“Gauges  green,  ready  to  lift,”  he  announeed  calmly.  Second  later.  Warlord  710 
was  airborne  and  headed  East. 

6,  Phase  V:  Flexible,  Lethal,  Survivable. 

Time;  0018L(1618Z) 

Warlord  710  skimmed  the  moonlit  waves  at  just  25  feet  AGE  (above  ground 
level)  and  over  300  knots — a  performance  enabled  as  much  by  the  aircraft’s  advanced 
automated  terrain/collision  avoidance  system  as  by  its  agile  airframe.  Shortly  after  take¬ 
off  from  the  Kyle.  JD’s  crew  had  managed  to  establish  direct  link  with  Warlord  704, 
currently  in  a  6,000  ft  orbit  off  the  coast  of  Goat  Island.  Now  the  two  aircraft  re¬ 
synchronized  their  tactical  data  and  began  automatically  pooling  their  sensor  information 
to  create  a  fused  tactical  plot.  Elsing  cross-fixed  ES  (electronic  support)  bearing-lines 
from  each  aircraft’s  receivers,  anti-aircraft  and  coastal  warning  radar  installations  on  the 
island’s  west  side  were  pinpointed.  An  overlay  of  their  predicted  coverage  areas 
continuously  updated  as  JD  and  his  crew  continued  inbound. 

Advances  in  modular  software  and  virtual  “black  boxes”  meant  that  the  Warlord 
aircraft  had  an  EW  (electronic  warfare)  suite  functionally  equal  to  the  now-retired  E/A- 
18G  Growlers.  Suppression  of  maritime  air  defenses  was  even  a  mission  that  their  crews 
were  required  to  train  to,  usually  as  part  of  team  with  another  rotorcraft  flying  in 
autonomous  mode.  Tonight  though,  JD  preferred  to  evade  the  rebel’s  air  defenses,  rather 
than  confront  them  directly.  Instead  of  anti-radiation  missiles  on  his  stub-wing  rails,  he 
had  a  load-out  of  eight  short-range  Griffin-C  dual-mode  IR/Easer  air-to-surface  missiles, 
and  a  twenty-millimeter  gun  pod. 

With  the  multi-spectrum  night-vision  system  built  into  his  helmet-mounted  cuing 
system,  JD  could  soon  see  the  craggy  profde  of  Goat  Island  becoming  visible  in  the 
distance.  Via  corn-relay  through  Warlord  704,  he  also  had  secure  voice  contact  with  the 
SEAL  platoon  leader. 

“We’re  at  LZ  Bravo,”  announced  the  Navy  frogman.  “We  broke  contact,  but 
they’ll  be  on  us  again  soon.  Say  ETA.” 
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“Warlord  710  will  be  overhead  in...  two  minutes,  thirty  seconds,”  JD  answered, 
consulting  his  tactical  display.  “Engaging  the  TELs  en-route.” 

“Good  luck!  Their  running  for  it.” 

Thanks  to  some  close  coordination  between  Elo  in  the  left  seat,  AW2  Stout  at  the 
sensor-operator  station,  and  Squirrel  back  aboard  the  Kyle,  the  shot  was  already  set  up. 
While  704  maintained  surveillance  over  the  TEE  convoy  from  a  safe  stand-off  range, 
710  would  swing  in  low  and  hug  the  rugged  coast-line  of  Goat  Island.  Masked  by  terrain, 
710  would  fire  a  volley  of  Griffin-C  missiles  once  in  range,  which  would  automatically 
climb  to  altitude,  and  hopefully  pick  up  the  laser  energy  from  704 ’s  target  designator.  At 
that  point,  they  would  arc  back  down  toward  the  road,  lock  onto  the  heat-signature  of  the 
vehicles  and  go  into  IR  mode  for  terminal  guidance. 

The  “shot  fans”  on  JD’s  moving  map  tactical  display  made  lining  up  for  the 
complex  shot  easy.  At  his  command,  Elo  triggered  the  first  shot.  A  Griffin  missile  burst 
off  the  left-hand  rail  with  a  sound  like  a  shotgun  going  off.  It  immediately  climbed 
skyward,  reporting  its  status  back  to  710  through  a  simple,  high-speed  data  link. 

“Missile  away.  Good  link.”  Elo  reported,  excitedly.  “704  has  it  now...  Good 
laser  energy...” 

“Eire  two.”  JD  directed. 

Elo  triggered  the  next  shot.  Eive  seconds  later,  the  third  Griffin  followed,  and  five 
seconds  after  that,  a  fourth  missile  was  airborne.  By  time  the  last  weapon  left  the  launch 
rail,  the  first  weapon  had  already  struck  its  target.  Three  more  closely  spaced  explosions 
lit  up  the  night  sky  in  rapid  succession. 

Elo  called  the  hits  over  the  ICS,  but  there  was  no  time  to  confirm  if  all  the  TEES 
were  destroyed.  That  could  wait  for  later;  every  byte  of  data  from  both  aircraft  was  being 
recorded  for  later  playback  anyway.  Right  now.  Warlord  710  had  other  matters  to 
attended  to;  namely,  getting  to  EZ  Bravo  on-time  for  their  overhead. 

Per  the  plan  they  had  worked  out  earlier  that  night  in  the  DIVTACS  session,  the 
crew  of  710  picked  up  their  next  waypoint,  and  directed  710  to  provide  covering  fire  in 
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autonomous  mode.  The  landing  zone  was  in  a  small  jungle  clearing  some  distance  from 
the  shore;  it  looked  exactly  the  way  it  had  in  the  simulator.  After  a  quick  reconnaissance 
pass,  JD  slowed  Warlord  710  and  dropped  below  the  treeline.  Before  his  wheels  even 
touched  down  in  the  grass,  a  group  of  dark  shapes  emerged  from  the  underbrush  and 
rushed  toward  the  waiting  rotorcraft.  In  quick  succession,  all  eight  SEALs  jumped 
aboard. 

“Clear!”  Yelled  AW2  Stout  into  the  ICS  from  the  door-gunner  position.  Without 
delay,  JD  pulled  in  power  and  executed  a  rapid  no-hover  take-off  Apparently  though,  it 
was  not  rapid  enough.  Just  as  they  shuddered  their  way  through  translational  lift  and 
rotorcraft’s  pusher  fans  started  applying  forward  thrust,  a  tracer  the  size  of  a  Forth-of- 
July  rocket  cut  right  across  the  windscreen.  That  definitely  wasn’t  small-arms  fire! 

A  second  later  -  before  JD  could  even  react  -  the  whole  airframe  resounded  with 
a  sharp,  brief  impact.  Every  MFD  in  the  cockpit  went  black  for  a  fraction  of  a  second,  but 
then  came  back  on-line. 

“Break  Eeft!”  commanded  the  normally  calm  voice  of  710’s  automated  copilot 
over  the  ICS.  JD  didn’t  question  the  call  -  even  if  it  was  from  an  software  program.  He 
raked  the  aircraft  over  on  its  side  and  pulled  hard.  For  a  moment,  as  the  dark-green  mass 
of  jungle  rushed  up  to  greet  him  through  the  cockpit  window,  he  thought  he  could  feel  a 
guiding  hand  adjusting  his  control-inputs — just  like  one  of  his  flight  instructors  at  NAS 
Whiting  Field  might  have  on  an  early  contact  flight.  “Reverse  turn,”  Hal  advised  again  a 
second  or  two  later.  Another  huge  tracer  flew  by  harmlessly. 

A  large  explosion  lit  up  the  jungle  behind  and  below  them  and  a  few  moments 
later,  the  robotic  voice  over  the  ICS  announced  “Threat  clear.  Proceed  on  course” 

Not  sure  what  had  just  happened,  but  positive  that  they  had  just  survived  a  very 
close  call,  JD  let  out  a  tense  breath  and  turned  westward  toward  the  first  waypoint  on 
their  egress  route. 

“Thanks  Hal,”  he  mumbled  into  the  microphone. 
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“Please  repeat  your  last,”  replied  the  automated  voiee.  “I  did  not  understand  your 


request.” 


7,  Phase  VI:  High-Fidelity  Dehrief 

Time;  0505L(2105Z) 

Almost  four  hours  after  reeovering  Warlord  710  and  704,  there  was  still  a  eurious 
crowd  milling  about  the  Kyle ’s  hangar  bay.  The  DIVTACS  kit  had  been  set  up  again  (this 
time  on  704)  and  the  night’s  mission  over  Goat  Island  was  being  replayed  now  for 
perhaps  the  fifth  time.  Everyone  on  the  ship  apparently  wanted  to  get  a  look;  including 
the  captain,  who  insisted  on  sitting  in  the  left  seat  and  having  JD  explain  every  last  thing 
that  had  happened  from  launch  to  recovery.  By  switching  back  and  forth  between  the 
recorded  viewpoints  of  both  710  and  704,  a  comprehensive  reconstruction  of  the 
engagement  had  been  quickly  pieced  together,  indicating  with  a  high  degree  of  certainty 
that  all  of  the  TELs  had  been  destroyed.  Of  course,  official  confirmation  of  that  would 
have  to  wait  until  the  intelligence  cell  at  CITE  completed  their  own  analysis  of  the 
mission  data,  but  in  the  meantime,  some  other  interesting  facts  had  come  to  light. 

To  begin  with,  the  reason  the  DIVTACS  was  set  up  on  704,  instead  of  710  was 
that  the  latter  aircraft — the  one  JD  and  his  crew  had  been  flying  in — had  a  rather  large 
hole  in  the  fuselage  from  a  23mm  anti-aircraft  shell.  The  mobile  gun  system  that  had 
fired  that  round  was  neutralized  moments  later  by  an  autonomously  launched  Griffin 
missile  from  704.  The  entire  incident  was  a  stunning  example  of  the  survivability 
provided  by  the  rotorcraft’s  advanced,  software-defined  mission  systems.  Warlord  710’s 
Avionics  Stack  I  (its  primary  avionics  server)  had  been  totally  destroyed  by  the  anti¬ 
aircraft  shell;  and  yet  the  aircraft  had  suffered  no  pilot-perceptible  loss  of  functionality. 
The  secondary  avionics  server  “Stack  11”  had  been  running  parallel  instances  of  all  flight 
and  mission  applications,  and  when  “Stack  I”  dropped-off  the  network,  failover  to  those 
parallel  instances  was  immediate  and  seamless.  In  the  seconds  following  the  event,  the 
system  was  even  able  to  help  guide  JD’s  break-lock  maneuver  with  verbal  advisories  and 
outer-loop  control  inputs.  That  had  been  a  close  one.  Eidar-altimeter  data  indicated  that 
they  had  been  less  than  ten  feet  from  slamming  into  the  ground  at  one  point. 


89 


Thoughts  of  that  seat-clenching  moment  were  turning  over  again  in  JD’s  mind  as 
he  finally  escaped  the  hangar  and  bay  and  walked  out  onto  the  flight  deck  to  watch  the 
sun  rise.  Flo  was  outside  as  well,  doing  the  same  thing. 

“You  remember  what  you  told  Squirrel  last  night  before  we  took  off?”  JD  asked 
after  a  few  casual  words. 

“About  being  a  klutz?” 

“No  -  about  Hal  having  your  back.” 

“Oh,  yeah,”  Flo  nodded.  “I  guess  he  had  both  of  our  backs,  didn’t  he?” 

“With  a  copilot  like  that,  I  might  even  survive  the  rest  of  this  tour  of  flying  with 
nuggets  like  you.” 
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VI.  CONCLUSION  AND  RECOMMENDATION 


A,  IMA2G  -  ARCHITECTURE  OF  CHOICE  FOR  THE  EVE 

Despite  the  risks  of  immature  teehnology  and  organizational  resistance  along  several 
critical  paths,  our  findings  indicate  that  IMA2G  is  an  overwhelming  a  favorable  model 
for  the  FVL’s  joint  common  architecture.  It  supports  the  speed,  agility,  range  and  payload 
goals  of  the  FVL  program  through  significant  SWAP  reductions;  will  help  ensure 
enhanced  aircraft-availability  by  eliminating  numerous  points  of  failure;  will  reduce 
manpower  footprint  by  streamlining  field-maintenance  and  adding  an  unmanned  option 
to  nominally  manned  platforms;  will  provide  a  common  architecture  across  manned  and 
unmanned  variants,  facilitating  Level-5  interoperability;  and  its  hardware  and  software 
modularity  will  help  contain  costs  for  maintenance  and  life-cycle  update. 

If  the  scope  of  required  attributes  and  outcomes  listed  in  the  program’s  ICD  is 
scaled  back  to  a  degree,  other  options  short  of  fully-realized  second-generation  IMA 
might  be  feasible  -  but  are  probably  ill-advised  in  the  long-term.  While  first-generation 
IMA  has  be  a  unqualified  success  in  recent  commercial  aircraft,  it  has  yet  to  demonstrate 
cost-effectiveness  in  a  multi-mission  military  platform.  Detractors  of  such  IMA-equipped 
aircraft  as  the  F-22,  for  instance,  point  out  the  difficulty  in  integrating  new  capabilities 
into  closely-coupled  systems.  IMA2G,  which  hosts  most  functions  as  un-modified 
software  instances  running  in  a  virtual  computing  environment  has  genuine  potential  to 
combine  the  SWAP  gains  of  earlier  integrated  avionics  with  the  modular  flexibility  of 
federated  mission  systems.  By  contrast,  the  practice  of  added  functionality  to  a  military 
aircraft  by  installing  an  endless  procession  of  marginally-integrated  black  boxes  has 
already  reached  its  practical  limit.  Evidence  of  this  can  be  seen  in  the  latest  AH-64E 
“Guardian”  Apaches,  and  recent  block-upgrades  to  E-16C  fighters,  which  make  use  of 
localized  IMA  architectures,  grafted  onto  federated  systems  in  order  to  deliver  additional 
functions  without  added  more  LRU’s  and  unnecessary  wiring.  Though  in  theory,  the 
same  could  be  done  for  the  EVL,  we  must  question  the  wisdom  of  handicapping  an  entire 
family  of  aircraft  from  birth  with  core  avionics  design  that  is  already  rapidly  becoming 
obsolete. 
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B,  EMBRACE  CHANGE,  REDUCE  THE  RISK 

A  better  option,  in  the  opinion  of  this  author,  is  to  embraee  fully  the  eoming  sea-ehange 
in  the  way  avionics  for  manned  aircraft  are  designed  and  implemented.  Like  all  future 
combat  vehicles,  the  FVL  will  be  expected  to  handle  an  extremely  complex  set  of 
mission  functions;  the  complexity  of  the  task  requires  an  equally  complex  suite  of 
systems  in  order  to  execute  it — and  the  problem  we  find  ourselves  in  today  is  that  our 
present  (document-driven)  means  of  moving  such  complex  systems  from  concept  to 
reality  is  no  longer  adequate  to  the  task. 

Model-Based  Systems  Engineering  (MBSE),  and  Modular  Open  Systems 
Architecture  (MOSA)  are  already  painting  the  way  forward.  Public-private-sector 
consortiums  such  as  EACE  (Euture  Airborne  Capabilities  Environment)  are  pressing 
ahead  establishing  new  industry-wide  technical  standards  to  help  modular  mission 
software  finally  become  a  reality;  while  in  Europe,  the  SCARLETT  group  (SCAlable  and 
Reconfigurable  ElecTronic  Technology)  is  channeling  government  investment  into 
model-based  testing  for  the  next  generation  of  integrated  avionics. 

In  light  of  the  clear  immaturity  of  such  technology  as  deterministic  multi-core 
processing  and  high-assurance  virtualization,  it  is  tempting  to  tread  a  cautious  path  with 
the  EVE.  The  entire  program  must,  indeed,  find  its  footing  in  an  acquisition  environment 
made  pessimistic  and  hostile  by  the  high-profile  struggles  of  the  E-35  Joint  Strike  Tighter. 
A  tepid  and  hesitant  advance  rarely  makes  for  effective  military  strategy  on  the  battlefield 
though,  and  we  suspect  that  it  will  do  no  better  within  the  framework  of  major  military 
systems  acquisition. 

If  we  allow  our  pessimism  to  translate  into  lukewarm  investment  in  the  coming 
revolution  in  aviation  systems  design,  we  will  almost  surely  create  a  self-fulfilling 
prophesy.  Radical  improvement  does  not  occur  without  committed  support.  Ideas  are  not 
enough.  Ironically,  the  best  way  to  reduce  risk  is  occasionally  to  pick  the  opportune 
moment  and  charge  full-speed  ahead.  With  regard  to  model-based  avionics  design, 
testing  and  validation — the  key  discipline  that  will  allow  us  to  build  a  successful  IMA2G 
Joint  Common  Architecture — that  time  is  upon  us  now. 
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C.  RECOMMENDATION  FOR  FURTHER  RESEARCH 

Though  this  study  of  software-defined  avionies  for  the  next  generation  of  rotary¬ 
wing  military  aircraft  may  have  succeeded  in  answering  a  few  of  the  questions  initially 
posed,  the  most  salient  result  is  probably  the  list  of  critical  research  areas  it  has 
highlighted.  These  directions  for  further  study  fall  into  three  broad  categories:  technical, 
organizational,  and  operational. 

a.  Technical  Research  Directions 

•  Study  of  candidate  Model-Based  Systems  Engineering  methodologies  to 
determine  which  is  best-suited  for  developing  military  software/hardware 
solutions,  including  capturing  the  complexities  of  human-cyber 
interaction. 

•  Rigorous  testing  to  verify  if  current  and  emerging  technology  can  assure 
deterministic  performance  in  multi-core  processing,  including  in 
installations  where  one  or  more  cores  are  deactivated. 

•  Survey  of  how  advanced  deterministic  network  applications  in  the 
automotive  industry  may  point  the  way  toward  parallel  developments  in 
military  aviation. 

•  Model  the  technical  requirements  that  would  be  needed  to  create  the  built- 
in  tactical  simulator  concept  described  in  this  paper. 

b.  Organizational  Research  Directions 

•  Study  and  develop  proposed  methods  to  integrate  data-model-based  design 

into  the  military  acquisition  system,  from  initial  requirements 
development,  all  the  way  to  operational  testing. 

•  Survey  both  successful  and  failed  open-source  technical  standards  in  the 
IT  industry  to  help  determine  how  best  to  implement  one  for  military 
avionics. 

c.  Operational  Research  Directions 

•  Assess  predicted  manpower-requirements  resulting  from  optionally- 

manned  FVL  aircraft  that  provide  extended  air-service  availability  to 
theatre  commanders. 


93 


•  Identify  new  mission-sets  that  the  unique  charaeteristics  of  sueh  aireraft 
might  allow  in  the  future.  Based  on  results,  determine  an  ideal  force- 
structure  of  FVL  variants. 

•  Study  the  impact  that  built-in  tactical  training  simulators  would  have  on 
aircrew  readiness.  Would  they  be  utilized  enough  in  the  deployed 
environment  to  justify  their  development? 
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APPENDIX  A.  DEPLOYABLE  INTEGRATED  VIRTUAL 
TACTICAL  SIMULATOR  (DIVTACS) 

In  Chapter  V  of  this  study,  we  introduced  a  proposed  concept  whereby  an 
IMA2G-equipped  FVL  aircraft  could  provide  deployed  ancrews  with  their  own  high- 
fidelity  tactical  simulator.  We  refer  to  this  notional  system  as  DIVTACS,  or  deployable 
integrated  virtual  tactical  simulator,  and  illustrate  the  concept  below. 
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APPENDIX  B.  TRL  DEFINITIONS,  DESCRIPTIONS,  AND 
SUPPORTING  INFORMATION 


Definition 

Description 

Basic  principles 
observed  and 
reported. 

Lowest  level  of  technology 
readiness.  Scientific  research 
begins  to  be  translated  into 
applied  research  and 
development  (R&D).  Examples 
might  include  paper  studies  of  a 
technology’s  basic  properties. 

Technology 
concept  and/or 
application 
formulated. 

Invention  begins.  Once  basic 
principles  are  observed, 
practical  applications  can  be 
invented.  Applications  are 
speculative,  and  there  may  be 
no  proof  or  detailed  analysis  to 
support  the  assumptions. 
Examples  are  limited  to  analytic 
studies. 

Analytical  and 
experimental 
critical  function 
and/or 

characteristic  proof 
of  concept. 

Active  R&D  is  initiated.  This 
includes  analytical  studies  and 
laboratory  studies  to  physically 
validate  the  analytical 
predictions  of  separate  elements 
of  the  technology.  Examples 
include  components  that  are  not 
yet  integrated  or  representative. 

Component  and/or 
breadboard 
validation  in  a 
laboratory 
environment. 

Basic  technological  components 
are  integrated  to  establish  that 
they  will  work  together.  This  is 
relatively  “low  fidelity” 
compared  with  the  eventual 
system.  Examples  include 
integration  of  “ad  hoc” 
hardware  in  the  laboratory 

Component  and/or 
breadboard 

Eidelity  of  breadboard 
technology  increases 

Supporting  Information 

Published  research  that 
identihes  the  principles 
that  underlie  this 
technology.  References  to 
who,  where,  when. 


Publications  or  other 
references  that  out-  line 
the  application  being 
considered  and  that 
provide  analysis  to 
support  the  concept. 


Results  of  laboratory  tests 
performed  to  measure 
parameters  of  interest  and 
comparison  to  analytical 
predictions  for  critical 
subsystems.  References  to 
who,  where,  and  when 
these  tests  and 
comparisons  were 

performed. _ 

System  concepts  that  have 
been  considered  and 
results  from  testing 
laboratory  scale 
breadboard(s).  References 
to  who  did  this  work  and 
when.  Provide  an  estimate 
of  how  breadboard 
hardware  and  test  results 
differ  from  the  expected 

system  goals. _ 

Results  from  testing 
laboratory  breadboard 
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TRL  Definition 


Description 


Supporting  Information 


validation  in  a 

relevant 

environment. 


significantly.  The  basic 
technological  components  are 
integrated  with  reasonably 
realistic  supporting  elements  so 
they  can  be  tested  in  a 
simulated  environment. 
Examples  include  “high- 
fidelity”  laboratory  integration 
of  components. 


System/subsystem  Representative  model  or 
model  or  prototype  prototype  system,  which  is  well 
demonstration  in  a  beyond  that  of  TRL  5 ,  is  tested 
relevant  ^  relevant  environment, 

environment.  Represents  a  major  step  up  in  a 

technology’s  demonstrated 
readiness.  Examples  include 
testing  a  prototype  in  a  high- 
fidelity  laboratory  environment 
or  in  a  simulated  operational 
environment. 


System  prototype 
demonstration  in  an 
operational 
environment 


Prototype  near  or  at  planned 
operational  system.  Represents 
a  major  step  up  from  TRL  6  by 
requiring  demonstration  of  an 
actual  system  prototype  in  an 
operational  environment  (e.g., 
in  an  aircraft,  in  a  vehicle,  or  in 
space). 


system  are  integrated  with 
other  supporting  elements 
in  a  simulated  operational 
environment.  How  does 
the  “relevant 
environment”  differ  from 
the  expected  operational 
environment?  How  do  the 
test  results  compare  with 
expectations?  What 
problems,  if  any,  were 
encountered?  Was  the 
breadboard  system  refined 
to  more  nearly  match  the 
expected  system  goals? 


Results  from  laboratory 
testing  of  a  proto-  type 
system  that  is  near  the 
desired  con-  figuration  in 
terms  of  performance, 
weight,  and  volume.  How 
did  the  test  environment 
differ  from  the  operational 
environment?  Who 
performed  the  tests?  How 
did  the  test  compare  with 
expectations?  What 
problems,  if  any,  were 
encountered?  What 
are/were  the  plans, 
options,  or  actions  to 
resolve  problems  before 
moving  to  the  next  level? 


Results  from  testing  a 
prototype  system  in  an 
operational  environment. 
Who  performed  the  tests? 
How  did  the  test  compare 
with  expectations?  What 
problems,  if  any,  were 
encountered?  What 
are/were  the  plans, 
options,  or  actions  to 
resolve  problems  before 
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TRL 

Definition 

Description 

Supporting  Information 

moving  to  the  next  level? 

8 

Actual  system 
completed  and 
qualified  through 
test  and 
demonstration 

Technology  has  been  proven  to 
work  in  its  final  form  and  under 
expected  conditions.  In  almost 
all  cases,  this  TRL  represents 
the  end  of  true  system 
development.  Examples  include 
developmental  test  and 
evaluation  (DT&E)  of  the 
system  in  its  intended  weapon 
system  to  deter-  mine  if  it  meets 
design  specifications. 

Results  of  testing  the 
system  in  its  final 
configuration  under  the 
expected  range  of 
environmental  conditions 
in  which  it  will  be 
expected  to  operate. 
Assessment  of  whether  it 
will  meet  its  operational 
requirements.  What 
problems,  if  any,  were 
encountered?  What 
are/were  the  plans, 
options,  or  actions  to 
resolve  problems  before 
finalizing  the  design? 

9 

Actual  system 
proven  through 
successful  mission 
operations. 

Actual  application  of  the 
technology  in  its  final  form  and 
under  mission  conditions,  such 
as  those  encountered  in 
operational  test  and  evaluation 
(OT&E).  Examples  include 
using  the  system  under 
operational  mission  conditions. 

OT&E  reports. 
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APPENDIX  C.  CURRENT  AND  EMERGING  STANDARDS  IN 

AVIONICS 

ARINC  429;  Mark  33  Digital  Information  Transfer  System  (BITS). 

Paper  and  PDF  eopies  available  (for  a  fee)  at: 
http://www.aviation- 

ia.eom/cf/store/eatalog.efm?prod_group_id=l&eategory_group_id=l 

ARINC  629;  Multi-Transmitter  Data  Bus. 

Paper  and  PDF  eopies  available  (for  a  fee)  at: 
http://www.aviation- 

ia.eom/ef/store/eatalog.cfm?prod_group_id=l&eategory_group_id=3 

ARINC  653;  Avionics  Application  Software  Standard  Interface. 

Paper  and  PDF  copies  available  (for  a  fee)  at: 
http://www.aviation- 

ia.com/cf/store/catalog.cfm?prod_group_id=l&category_group_id=3 

ARINC  664/AFDX;  Aircraft  Data  Network. 

Paper  and  PDF  copies  available  (for  a  fee)  at: 
http://www.aviation- 

ia.com/cf/store/catalog.cfm?prod_group_id=l&category_group_id=3 

MIL-STD-1553;  Military  Standard:  Aircraft  Internal  Time  Division  Command/Response 
Multiplex  Data  Bus. 

Multiple  resources  can  be  found  at:  http://www.milstdl553.com/ 

Various  PDF  editions  can  be  accessed  at: 

http://everyspec.eom/MIL-STD/MIL-STD-1500-1599/MIL-STD-1553B_NOTICE- 

4_23430/ 

MIL-STD-1773;  Military  Standard:  Fiber  Optics  Mechanization  of  an  Aircraft  Internal 
Time  Division  Command  Response  Multiplex  Data  Bus. 

PDF  copy  available  for  download  at: 

http://everyspec.eom/MIL-STD/MIL-STD-1700-1799/MIL-STD-1773_25257 

IEEE  1394;  IEEE  Standard  for  a  High  Performance  Serial  Bus. 

Current  (2008)  version  available  at: 
http://standards.ieee.org/findstds/standard/1394-2008.html 

AS6802;  Deterministic  Ethernet  and  Unified  Networking. 

PDE  copy  available  (for  a  fee)  at:  http://standards.sae.org/as6802/ 

EACE  Technical  Standard;  Euture  Airborne  Capability  Environment  Technical  Standard. 
Current  (2.1)  version  available  at:  http://www.opengroup.Org/face/tech-standard-2.l 
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